[nanomsg] Re: initial code repo for Go version of SP protocols
- From: Alex Elsayed <eternaleye@xxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Tue, 25 Mar 2014 11:56:22 -0700
Martin Sustrik wrote:
> -----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.
My point is that if you don't have congestion control in your transport, you
then are expected to implement TCP-friendly congestion control in your
application protocol. See: Bittorrent, and how in moving to UDP in
implemented LEDBAT.
If you don't, then you get congestion collapse that utterly ruins the
network - including for your protocol. Congestion control is considered
mandatory; if it's not in the lower layers then you get told to put it in at
the top.
> 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.
That is somewhat reasonable - limiting size to the MTU, etc. But congestion
control isn't considered a 'problem with UDP' in that sense; it's more "If
you use UDP, you accept the responsibility of ensuring you use CC like a
good netizen. If you can't, use a different transport."
> If the user is not happy with what UDP offers, let him use a different
> protocol, be it DCCP or something else.
Except CC isn't considered the user's decision, since it has a drastic
effect on the health of the overall network.
> 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."
And they say "The problem isn't with UDP" - the rule is "you have to have
CC, and if the transport doesn't do it for you it's your job."
>>> 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
Less "frowned upon" than "hahahahaha good luck deploying that on the public
internet" due to the fact that the original narrow waist (IP) has gotten
corseted up tight first to UDP and TCP, and then further with NAT and
"helpful" middleboxes.
The Tng project from the DeDiS group at Yale has some papers on the problem,
and a proposed way around it - in particular, putting SP over the Minion
suite of protocols might work very well indeed.
Other related posts:
