UDP clamped on service provider links

Ca By cb.list6 at gmail.com
Thu Jul 30 21:31:59 UTC 2015


On Thu, Jul 30, 2015 at 2:04 PM, Ted Hardie <ted.ietf at gmail.com> wrote:

> On Thu, Jul 30, 2015 at 1:45 PM, John Kristoff <jtk at cymru.com> wrote:
>
> > On Mon, 27 Jul 2015 19:42:46 +0530
> > Glen Kent <glen.kent at 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,
>
> Ted
>

We will install a middlebox to strip off the UDP and expose the SCTP
natively as the transport protocol !

Patent pending!

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 :)



More information about the NANOG mailing list