Re: [rtcweb] Data channel comments and questions

[Eric Rescorla <[e-mail]>]

On Thu, Mar 29, 2012 at 10:23 PM,  <[e-mail]> wrote:
> 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.

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