Re: [Stackevo-discuss] [tsvwg] [Stackevo] draft-byrne-opsec-udp-advisory

[Joe Touch <[e-mail]>]

Hi, Dave,

Yes, I should have included UDPLite in the list below and it's a very
direct replacement for UDP when used as you indicate.

However, one goal of a transition out of UDP might be to include
integrated congestion control, for which either SCTP or DCCP would be a
better alternative.

It would be interesting to know if you've tested UDPLite through
consumer-grade NATs or across any CGNs - i.e., network devices that need
to keep transport-based state, not just firewalls.

Joe

On 7/24/2015 10:43 AM, Dave Taht wrote:
> I note that udplite is widely available, understood by bsd and linux,
> passed by at least a few firewalls, and if you don't use the reduced
> checksum feature, indistinguishable from udp... and one line of app
> code to use...
> 
> ... and widely underused. I did quite a bit of testing of it on ipv6
> paths, and even converted a few tools like mosh and netperf to use it
> for a while. Attempting to at least measure how well udplite gets
> around would be a starting place for a new protocol, and at least
> probing for the ability to use it in, say, quic might make some
> headway.
> 
> My overall objection, however, to a new connectionless protocol for
> "good udp applications" is that we had no idea how many crap udp
> applications we had at the time we wrote them.
> 
> On Fri, Jul 24, 2015 at 7:13 PM, Joe Touch <[e-mail]> wrote:
>> I'm left with the following questions:
>>
>> - if you want a new UDP protocol number, why not just us 33 (DCCP)?
>>
>> - if NATs would not be an issue to a new transport, why has it inhibited
>> all the recent attempts? (DCCP, SCTP)
>>
>> Although I appreciate the implications on TAPS for "do what I mean"
>> negotiation of alternate transports, TAPS doesn't solve either of the
>> issues above.
>>
>> AFAICT, they both highlight:
>>
>> a) why this is hard
>>
>> b) why this doesn't actually need a new IANA transport protocol codepoint
>>
>> Joe
>>
> 
> 
>