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

[Dave Taht <[e-mail]>]

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
>



-- 
Dave Täht
worldwide bufferbloat report:
http://www.dslreports.com/speedtest/results/bufferbloat
And:
What will it take to vastly improve wifi for everyone?
https://plus.google.com/u/0/explore/makewififast