[nanomsg] Re: initial code repo for Go version of SP protocols
- From: Garrett D'Amore <garrett@xxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Tue, 25 Mar 2014 13:14:31 -0700
On Mar 25, 2014, at 11:56 AM, Alex Elsayed <eternaleye@xxxxxxxxx> wrote:
> 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.
My take on this is that if you want this, you should TCP. I wouldn’t seriously
consider UDP for a network wide spanning protocol unless the protocol could
reasonably expect to occasionally drop packets without undue harm to
applications. Your earlier points about fragmentation here are salient, but I
wouldn’t use UDP at all if I wanted to exchange big frames. That’s just nuts.
Put another way, if my protocol is notionally similar to ICMP echo, or
multicast DNS, or something like that, I don’t need congestion control. If I’m
going to use UDP to stream tons of data, then *yeah*, I need it. I don’t think
nanomsg/SP should tackle that problem right now. Frankly, the approach to
solving this is probably going to be application specific. (In the case of a
streaming protocol, you probably just elect to drop frames. Hopefully the fact
that you’re doing so is somewhere noticed by the app which reduces its transmit
rate.
>
>> 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 you’re going to flood traffic, CC is needed, agreed. Not all applications —
not even most — need this. If I send one packet a second, CC is pointless.
Again, if I’m doing some kind of bulk transfer over UDP, then you need a real
solution. That’s out of scope here.
My guess is that UDP is a poor choice for these apps. SCTP or something else
is probably better. Don’t stream over UDP. :-)
>
>> 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.
It is though. UDP is accessible directly to the user. A bad user can flood
UDP over the wire. Sites that care about this fix it in the routers, QoS, etc.
Nanomsg can’t fix that problem.
>
>> 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.”
Pass that buck! Seriously, if CC is needed, do it at the application, or map
to a lower level protocol (DCCP) that offers it.
UDP is a trivial transport; for trivial needs its fine. Probably I would avoid
it like the plague for times when I had to worry about CC.
>
>>>> 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" middle boxes.
Yep.
>
> 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.
There are probably lots of other bottom layers that can be experimented with.
With the Go work I’ve done, it usually doesn’t take more than an hour to build
a new transport, unless I have to build the underlying code to support the
transport itself. (For inproc, I did that, and it took a few hours. But for
TLS, it took about 30 minutes to implement the transport glue between SP and
Go’s native TLS support. The IPC layer took about 10 minutes to adapt from
TCP.)
— Garrett
Other related posts:
