Subject: [rtcweb] Data channel comments and questions

From: <[email-masked]>
Date: Thu, 29 Mar 2012 20:23:28 +0000

Hi,

Some comments on the data channel proposal:

1. Congestion control: If no real-time sessions are on, TCP-style loss-driven congestion control is fine. However, if voice/video session is up, such congestion control would be disasterous to the real-time traffic quality if sendind or receiving more than a slight amount of data. Especially in mobile access networks the user would bloat his/her own buffers very easily. In that case, some less-than-best-effort congestion control algorithm á la LEDBAT would be required. It would be best to make this a MUST requirement on implementations, otherwise we will get a lot of crappy video even if the codec was better than H.261 :-)

2. Multihoming and interface switching: I don't suggest going for the multipath support on the SCTP level. I think it would be best to deal with this through ICE in the same way as for RTP, i.e. adding and removing candidates as interfaces become available or go. Or let the application handle it by creating a new data channel and continue from the breakpoint. The most important requirement is that the application gets notified about these changes downstrairs so it can act. 

3. HTTP tunneling: In practice we are going to need HTTP tunneling last-resort option for the data channel as well. If doing so, what will the protocol stack look like? Is it SCTP/DTLS/UDP/HTTP/TLS/TCP? Or can we collapse some of these layers. I think we'd better.

Markus

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 29 Mar 2012 22:27:44 +0200

> 3. HTTP tunneling: In practice we are going to need HTTP tunneling last-resort option for the data channel as well. If doing so, what will the protocol stack look like? Is it SCTP/DTLS/UDP/HTTP/TLS…

I don't think I understand point 3. Why would we need HTTP tunneling?
If we can bring
up a bidirectional UDP channel, then why would we need to run HTTP over it?

-Ekr

---

From: <[email-masked]>
Date: Thu, 29 Mar 2012 20:36:55 +0000

Hi,

Eric Rescorla [mailto:[email-masked]] wrote:
>>
>> 3. HTTP tunneling: In practice we are going to need HTTP tunneling last-
>resort option for the data channel as well. If doing so, what will the protocol
>stack look like? Is it SCTP/DTLS/UDP/HTTP/TLS/TCP? Or can we collapse some
>of these layers. I think we'd better.
>

Ah, sorry for not being clear. I mean a situation where we can't setup the UDP channel, if one endpoint is for instance in a corporate network from where only HTTP or HTTPS is allowed. So presumably we'd have to support some kind of HTTP or TLS encapsulation/tunneling for the data channel as well, from the endpoint to some kind of relay. But how would the end-to-end data channel look like then? I.e. what would be sent over the tunnel?

Markus

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 29 Mar 2012 22:48:17 +0200

> Ah, sorry for not being clear. I mean a situation where we can't setup the UDP channel, if one endpoint is for instance in a corporate network from where only HTTP or HTTPS is allowed. So presumabl…

I had sort of assumed that people would use that HTTP/HTTPS encapsulation only
to a relay which emitted UDP, so that that encapsulation wouldn't be end-to-end
in the general case.

-Ekr

---

From: <[email-masked]>
Date: Thu, 29 Mar 2012 20:53:51 +0000

Hi,

Eric Rescorla <[email-masked]> wrote:
>
>I had sort of assumed that people would use that HTTP/HTTPS encapsulation
>only to a relay which emitted UDP, so that that encapsulation wouldn't be
>end-to-end in the general case.
>

Makes sense and now that I think of it, it's actually quite clear that it can be done in the same way as with TURN. But SCTP/DTLS would be e2e in any case, and they'd be tunneled over HTTP/HTTPS (and TCP). Well, perhaps that's not so bad for the last resort case.

Markus

---

From: <[email-masked]>
Date: Thu, 29 Mar 2012 21:04:34 +0000

>
>Ah, sorry for not being clear. I mean a situation where we can't setup the UDP
>channel, if one endpoint is for instance in a corporate network from where
>only HTTP or HTTPS is allowed. So presumably we'd have to support some kind
>of HTTP or TLS encapsulation/tunneling for the data channel as well, from the
>endpoint to some kind of relay. But how would the end-to-end data channel
>look like then? I.e. what would be sent over the tunnel?
>

There's by the way at least one other use case where UDP-based data channel sucks. If you want to keep it up for a long time for some infrequent messaging, keeping the NAT state up by a keepalive every ~30s. would drain the battery on a mobile device. To solve that case some kind of TCP-based variant would be needed, at least between the mobile endpoint and a relay. TURN-TCP, I guess. If the other end was still using UDP and doing frequent keepalives, I suppose the relay would unfortunately forward them as well causing the same ill effect. 

I'm not sure if there are apps that would need to keep the data channel up infrequently used, though. Or should they just use the "signaling" path (HTTP, websockets) for that type of purposes. 

Markus

---

From: Salvatore Loreto <[email-masked]>
Date: Fri, 30 Mar 2012 21:15:00 +0200

Hi Markus,

see in line

> 1. Congestion control: If no real-time sessions are on, TCP-style loss-driven congestion control is fine. However, if voice/video session is up, such congestion control would be disasterous to the…
good point worth to discuss

the congestion control algorithm in the actual SCTP open source userland 
implementation is a TCP-friendly congestion control.
As I said during the presentation we can change it if we see the reason 
not to use it (and you have already some good one)...
however it should be clear that at moment SCTP does not have any way to 
negotiate the congestion control algorithm to use in an association.

So whatever we choose it will be the one used in all the possible 
scenarios (e.g. voice/video session up or down, etc).

> 2. Multihoming and interface switching: I don't suggest going for the multipath support on the SCTP level. I think it would be best to deal with this through ICE in the same way as for RTP, i.e. ad…
that is exact the proposal in the data-channel draft.
Anyway you can not use multihoming because of the fact that SCTP runs on 
top of DTLS
> 3. HTTP tunneling: In practice we are going to need HTTP tunneling last-resort option for the data channel as well. If doing so, what will the protocol stack look like? Is it SCTP/DTLS/UDP/HTTP/TLS…

this is something to figure it out.
Eric proposal make sense to me;
another possibility would be use WebSocket when you have to tunneling 
data over HTTP/HTTPS.

Salvatore

-- 
Salvatore Loreto, PhD
www.sloreto.com

---

From: Randell Jesup <[email-masked]>
Date: Fri, 30 Mar 2012 16:43:40 -0400

On 3/30/2012 3:15 PM, Salvatore Loreto wrote:
>> 1. Congestion control: If no real-time sessions are on, TCP-style
>> loss-driven congestion control is fine. However, if voice/video
>> session is up, such congestion control would be disasterous to the
>> real-time traffic quality if sendind or receiving more than a slight
>> amount of data. Especially in mobile access networks the user would
>> bloat his/her own buffers very easily. In that case, some
>> less-than-best-effort congestion control algorithm á la LEDBAT would
>> be required. It would be best to make this a MUST requirement on
>> implementations, otherwise we will get a lot of crappy video even if
>> the codec was better than H.261 :-)

Correct; please also see the presentation from the rtcweb Interim 
meeting in February that I gave; one issue it covered was congestion 
control.

We definitely want to both be able to balance bandwidth used by data 
channels versus media and to avoid data channels causing congestion that 
forces the media channels to degrade.

This could be done by:

a) developing a 'merged' congestion control regime for the media 
channels and the data channels.  As we're already getting a "total 
bandwidth" notification from the receiver, that calculation could 
include data channels, and let the sender allocate bits to media and the 
data channels according to that information.  In this scenario, the data 
channel code itself would be slaved to a wider congestion control.

b) run separate congestion control for the data channels based on a 
low-delay variant of classic TCP, such as Cx-TCP.  It so happens that 
the FreeBSD SCTP implementation includes a low-delay congestion 
algorithm based on an ancestor of the current Cx-TCP work.

Cx-TCP (for links see the Interim slides) runs in a low-delay fashion 
unless it's fighting with long-lived/saturating TCP flows, where it will 
transition into a loss-based behavior (with longer delay), and 
transition back if the TCP flows drop below bottleneck bandwidth.

c) run classic loss-based congestion control (the default), but put an 
external bandwidth limiter on it controlled by the main application and 
congestion code, limiting the data channels to a specified amount or 
fraction of the media channels.

d) run classic loss-based congestion control and let it compete with 
media; don't send large amounts of data, or pace it in the application. 
  Or live with the data channel killing your media.

> negotiate the congestion control algorithm to use in an association.

Correct, though we could fix that - and we could give the JS control and 
let the app decide, since data channels are largely within-app 
proprietary connections.

>> 2. Multihoming and interface switching: I don't suggest going for the
>> multipath support on the SCTP level. I think it would be best to deal
>> with this through ICE in the same way as for RTP, i.e. adding and
>> removing candidates as interfaces become available or go. Or let the
>> application handle it by creating a new data channel and continue from
>> the breakpoint. The most important requirement is that the application
>> gets notified about these changes downstrairs so it can act.

Correct, though there was some in-room discussion of running it over 
multiple DTLS connections to support smooth handoff across interfaces 
(think mobile and 4g<->WiFi switchover).

-- 
Randell Jesup
[email-masked]