nanog mailing list archives
Re: UDP clamped on service provider links
From: Ted Hardie <ted.ietf () gmail com>
Date: Fri, 31 Jul 2015 10:01:04 -0700
On Thu, Jul 30, 2015 at 2:31 PM, Ca By <cb.list6 () gmail com> wrote:
On Thu, Jul 30, 2015 at 2:04 PM, Ted Hardie <ted.ietf () gmail com> wrote:On Thu, Jul 30, 2015 at 1:45 PM, John Kristoff <jtk () cymru com> wrote:On Mon, 27 Jul 2015 19:42:46 +0530 Glen Kent <glen.kent () gmail com> wrote:Is there a reason why this is often done so? Is this because UDP is stateless and any script kiddie could launch a DOS attack with a UDP stream?State, some form of sender verification and that it and most other commonly used protocols besides TCP do not generally react to implicit congestion signals (drops usually).Hmmm. The WebRTC stack has a pretty explicit form of getting and then maintaining consent; it also rides on top of UDP (SRTP/UDP for media and SCTP/DTLS/UDP for data channels). Because both media and data channels go from peer to peer, it has no preset group of server addresses to white list (the only way I can see to do that would be to force the use of TURN and white list the TURN server, but that would be problematic for performance). How will you support it if the default is to throttle UDP? Clue welcome, TedWe will install a middlebox to strip off the UDP and expose the SCTP natively as the transport protocol ! Patent pending!
Yeah, it's SCTP over DTLS over UDP, so stripping the UDP is going to give you: nothing. This may be WAI for some networks, of course.
RTCweb made a series of trade offs. Encapsulating SCTP in UDP is one of them... the idea at the time was the this is only WebRTC 1.0, so we'll do a few silly things to ship it early. As i am sure you know :)
All of engineering is trade-offs. But I'm asking about a different one here: media traffic often runs over udp when RTP/SRTP is involved and with WebRTC some datachannel traffic will as well. John's work in university environment he cited was used fixed limits for all protocols other than TCP, based on the idea that the others either had no congestion control or limited consent. Those issues shouldn't hit WebRTC which has robust consent and some congestion control (circuit breakers at the moment and more soon). How do we balance that out? regards, Ted
Current thread:
- UDP clamped on service provider links Glen Kent (Jul 27)
- Re: UDP clamped on service provider links Christopher Morrow (Jul 27)
- Re: UDP clamped on service provider links Ray Soucy (Jul 27)
- Re: UDP clamped on service provider links John Kristoff (Jul 30)
- Re: UDP clamped on service provider links Ted Hardie (Jul 30)
- Re: UDP clamped on service provider links Ca By (Jul 30)
- Re: UDP clamped on service provider links Ted Hardie (Jul 31)
- Re: UDP clamped on service provider links Ted Hardie (Jul 30)
- Re: UDP clamped on service provider links Jason Baugher (Jul 30)
- Re: UDP clamped on service provider links Matt Hoppes (Jul 30)
- Re: UDP clamped on service provider links Jason Baugher (Jul 30)
- Re: UDP clamped on service provider links Randy Bush (Jul 30)
- Re: UDP clamped on service provider links Brad Fleming (Jul 31)
- Re: UDP clamped on service provider links John Kristoff (Jul 31)
- Re: UDP clamped on service provider links Christopher Morrow (Jul 31)
- Re: UDP clamped on service provider links Jon Lewis (Jul 31)
- Re: UDP clamped on service provider links Tom Sands (Jul 30)
- Re: UDP clamped on service provider links Jason Baugher (Jul 30)