Subject: [Dart] ICE might send your traffic over TCP

From: Jonathan Lennox <[email-masked]>
Date: Wed, 23 Jul 2014 20:16:44 +0000

This is the point I brought up at the mic today about ICE and TCP candidates.

ICE, effectively (in the modes used for RTP and the like, i.e. as used in WebRTC-style contexts), presents an API as though it’s sending datagrams.  However, because ICE includes TCP candidates (both ICE-TCP and TURN-TCP), sometimes this “datagram" traffic will end up actually going over TCP instead, and depending on your implementation this will often be invisible to the higher-level code.

When this happens, it would be a bad thing if the low-level per-packet DSCP markings you were trying to use on UDP were applied to the TCP connection.  Even beyond the usual problems with mixing DSCP markings on a TCP connection, these framed TCP streams are usually created in userspace, so the packetization you expected from your API won’t be the packetization of the TCP on the wire.

How (say) a WebRTC implementation should handle API requests for multiple drop precedences when the underlying ICE channel is TCP is unclear to me.

Jonathan Lennox

---

From: <[email-masked]>
Date: Thu, 24 Jul 2014 09:54:22 +0200

Jonathan,

Let's briefly discuss your point below: Different drop precedences are required if congestion within a PHB group may occur. TCP is designed for reliable transport. In case of a loss, TCP will reduce bandwidth and retransmit the dropped information. I'm not an RTP expert. The few applications known to me don't seem to benefit from such a behavior, if a single application flow uses different drop precedence levels in combination with TCP.

It may make sense to have different TCP flows marked by different drop precedences. The less important TCP flows get throttled in the case of congestion. But is there a need to avoid re-ordering across different drop precedences, which is an AF PHB group feature? Again, I'm not an RTP expert - but that doesn't sound like making a lot of sense too. 

In general, I'd be interested to learn, if some applications were benefitting from ECN (or a congestion indication by marking rather than by dropping). Independent from the question whether they use TCP or RTP transport. 

Regards,

Ruediger

-----Message-----
From: Dart [mailto:[email-masked]] On behalf of Jonathan Lennox
Subject: [Dart] ICE might send your traffic over TCP

[snip]

Jonathan Lennox

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 24 Jul 2014 13:00:49 +0000

I don’t think different drop precedences would be useful in respect to TCP.

The problem is that the way the WebRTC APIs are structured, it’s not necessarily clear to an application that its media traffic is indeed going over TCP, so it might make precedence requests that the browser implementing the APIs can’t (and shouldn’t try to) satisfy.

The question is how the browser should behave when that happens.  I spoke to Cullen about this, offline, after the DART session, and I believe he had a simple proposal.

---

From: "Black, David" <[email-masked]>
Date: Thu, 24 Jul 2014 09:25:30 -0400

> I don't think different drop precedences would be useful in respect to TCP.

Clarification: "in respect to TCP" -> "within a single TCP connection".

IMHO, Ruediger's larger overall point is valid:

> > It may make sense to have different TCP flows marked by different drop
> precedences. The less important TCP flows get throttled in the case of
> congestion.

Thanks,
--David

> -----Original Message-----
> From: Dart [mailto:[email-masked]] On Behalf Of Jonathan Lennox
> Sent: Thursday, July 24, 2014 9:01 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Dart] ICE might send your traffic over TCP
> 
> I don't think different drop precedences would be useful in respect to TCP.
> 
> The problem is that the way the WebRTC APIs are structured, it's not
> necessarily clear to an application that its media traffic is indeed going
> over TCP, so it might make precedence requests that the browser implementing
> the APIs can't (and shouldn't try to) satisfy.
> 
> The question is how the browser should behave when that happens.  I spoke to
> Cullen about this, offline, after the DART session, and I believe he had a
> simple proposal.
> 
> > Let's briefly discuss your point below: Different drop precedences are
> required if congestion within a PHB group may occur. TCP is designed for
> reliable transport. In case of a loss, TCP will reduce bandwidth and
> retransmit the dropped information. I'm not an RTP expert. The few
> applications known to me don't seem to benefit from such a behavior, if a
> single application flow uses different drop precedence levels in combination
> with TCP.
> >
> > It may make sense to have different TCP flows marked by different drop
> precedences. The less important TCP flows get throttled in the case of
> congestion. But is there a need to avoid re-ordering across different drop
> precedences, which is an AF PHB group feature? Again, I'm not an RTP expert -
> but that doesn't sound like making a lot of sense too.
> >
> > In general, I'd be interested to learn, if some applications were
> benefitting from ECN (or a congestion indication by marking rather than by
> dropping). Independent from the question whether they use TCP or RTP
> transport.
> >
> > Regards,
> >
> > Ruediger
> >
> >
> >
> >
> > -----Message-----
> > How (say) a WebRTC implementation should handle API requests for multiple
> drop precedences when the underlying ICE channel is TCP is unclear to me.
> >
> > Jonathan Lennox
> >
> >
> 
> _______________________________________________
> Dart mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dart

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 24 Jul 2014 13:31:19 +0000

>> precedences. The less important TCP flows get throttled in the case of

Yes, agreed.  Sorry, my sloppy wording.

---

From: Ben Campbell <[email-masked]>
Date: Thu, 24 Jul 2014 15:44:43 -0400

(as individual)

> The question is how the browser should behave when that happens.  I spoke to Cullen about this, offline, after the DART session, and I believe he had a simple proposal.

What would we expect DART to say about this? It seems to me that we should point out that we think different drop precedences for a single TCP connections doesn't make sense. But it is RTCWEB's issue to think things through if they have a use case that might make this happen, isn't it?

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 24 Jul 2014 17:16:40 -0400

> What would we expect DART to say about this? It seems to me that we should point out that we think different drop precedences for a single TCP connections doesn't make sense. But it is RTCWEB's iss…

Maybe not for dart, but for turn: tunnel the drop precedence through 
turn so it can be applied on the other end???

	Thanks,
	Paul

---

From: "Black, David" <[email-masked]>
Date: Thu, 24 Jul 2014 18:37:39 -0400

> >> the APIs can't (and shouldn't try to) satisfy.

I agree ... fortunately, the browser implementation of the APIs has to translate
from the application priority to DSCP .  As ICE is also running in that browser,
that API implementation should know whether ICE did send all the traffic over TCP
 in which case, it has to pick once DSCP and use it for all traffic :-(.

> > What would we expect DART to say about this? It seems to me that we should
> > point out that we think different drop precedences for a single TCP
> > connections doesn't make sense. But it is RTCWEB's issue to think things
> > through if they have a use case that might make this happen, isn't it?

The normative text for that single DSCP usage  will wind up in the
rtcweb-transports draft (just confirmed in the rtcweb meeting this afternoon),
but it seems useful to repeat this in the DART draft and extend it to include
TURN use of TCP, both client to TURN server and TURN server to peer.

> turn so it can be applied on the other end???

Unless specified/deployed TURN can already do that, it's out of scope for DART,
IMHO.

Thanks,
--David

> From: Dart [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Thursday, July 24, 2014 5:17 PM
> To: [email-masked]
> >> The question is how the browser should behave when that happens.  I spoke
> to Cullen about this, offline, after the DART session, and I believe he had a
> simple proposal.
> >>
> >
> > What would we expect DART to say about this? It seems to me that we should
> point out that we think different drop precedences for a single TCP
> connections doesn't make sense. But it is RTCWEB's issue to think things
> through if they have a use case that might make this happen, isn't it?
>