UDP clamped on service provider links

Fri Jul 31 17:01:04 UTC 2015

On Thu, Jul 30, 2015 at 2:31 PM, Ca By <cb.list6 at gmail.com> wrote:

>
>
> 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!
>
>
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