[nanomsg] Re: initial code repo for Go version of SP protocols

  • From: Martin Sustrik <sustrik@xxxxxxxxxx>
  • To: nanomsg@xxxxxxxxxxxxx
  • Date: Tue, 25 Mar 2014 14:45:46 +0100

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Alex,

> Agreed. Relying on IP fragmentation and going forward with a 
> simplistic UDP protocol (as outlined in the RFC) seems to be the
> best idea.
> 
>> Doing this would go over like a lead balloon in the IETF, for the
>> simple reason that it offers zero capability for congestion
>> control.

I think you are missing the big point here: We are not trying to build
a new L4 protocol. We are operating on a layer above L4 which happens
to be able to use different L4 protocols. And one of those protocols
happens to be UDP.

Thus, if user wants to use UDP, let him do it, but let's not try to
fix any problems with UDP. If UDP cannot transport messages larger
than MTU, so be it. If UDP offers packet fragmentation, so be it. Et c.

If the user is not happy with what UDP offers, let him use a different
protocol, be it DCCP or something else.

In other words, in IETF you present it as "This is how our higher
level protocols we map to UDP. If you are not happy with UDP go to
Transport Area WGs and complain there."

>> Doing it over DCCP is better, but the information needed for CC
>> (ACK/NAK) is also sufficient for retransmission - thus making it
>> something of a moot point.

My impression was that DCCP is frowned upon in IETF as well, but that
may be just the people I've met.

Anyway, one interesting issue with UDP would be how to adapt REQ/REP
protocol to use it. At the moment each REQ/REP message contains stack
of "connection IDs" to be able to route the reply back to the
requester. However, with UDP being connectionless, we would have to
store IP addresses there instead of IDs. But then we have both IPv4
and IPv6. Et c.

Martin

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTMYiKAAoJENTpVjxCNN9YSh0H/1ZMN2I2Rp8d+FdBKqIj0fFy
BOCGFbD7VVbgbwxFmwKJymWzZ6nv//cydzeeZqs9a2Khxlf+4a0FBcZ8l2wohtnP
gx/wI2JdaDcagddv6VROhlHg2vz3D7AFCD8ItuPclFX69G4jSwZg+K4o818zGTCT
aiYi2wAFOWuwHlLZvei1MMxHPiI5nECZYcJeu23h6WmjSRCaHmQfAbgEwYR0dVxB
0wlbL8ZIiFmvv+MIyc4/iO64JhF57gOC0jntf94U0oihnY1e4/WQug4EVSDspq1i
ZSHD7ov7JG6Dc4Dcq6+ObuM7JU5n8WM0uCNSrpkCGU/8tS5236Tbu4LTc6mEtLc=
=ue/7
-----END PGP SIGNATURE-----

Other related posts: