IETF Logo Mail Archive

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

Jonathan Lennox <jonathan@vidyo.com> Thu, 24 July 2014 13:00 UTC

Return-Path: <jonathan@vidyo.com>
X-Original-To: dart@ietfa.amsl.com
Delivered-To: dart@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D82001A02ED for <dart@ietfa.amsl.com>; Thu, 24 Jul 2014 06:00:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJREI1nowidP for <dart@ietfa.amsl.com>; Thu, 24 Jul 2014 06:00:53 -0700 (PDT)
Received: from server209.appriver.com (server209d.appriver.com [8.31.233.119]) (using TLSv1 with cipher DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00DD51A02EC for <dart@ietf.org>; Thu, 24 Jul 2014 06:00:52 -0700 (PDT)
X-Note-AR-ScanTimeLocal: 7/24/2014 9:00:51 AM
X-Policy: GLOBAL - vidyo.com
X-Policy: GLOBAL - vidyo.com
X-Primary: jonathan@vidyo.com
X-Note: This Email was scanned by AppRiver SecureTide
X-Virus-Scan: V-
X-Note-SnifferID: 0
X-Note: TCH-CT/SI:0-132/SG:2 7/24/2014 9:00:01 AM
X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.948581 p=-0.971047 Source White
X-Signature-Violations: 0-0-0-5344-c
X-Note-419: 15.6006 ms. Fail:1 Chk:1335 of 1335 total
X-Note: SCH-CT/SI:1-1335/SG:1 7/24/2014 9:00:45 AM
X-Note: Spam Tests Failed:
X-Country-Path: ->UNITED STATES->
X-Note-Sending-IP: 162.209.16.213
X-Note-Reverse-DNS: mail2.vidyo.com
X-Note-Return-Path: jonathan@vidyo.com
X-Note: User Rule Hits:
X-Note: Global Rule Hits: G335 G336 G337 G338 G342 G343 G453
X-Note: Encrypt Rule Hits:
X-Note: Mail Class: VALID
X-Note: Headers Injected
Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 141922916; Thu, 24 Jul 2014 09:00:51 -0400
Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0195.001; Thu, 24 Jul 2014 08:00:50 -0500
From: Jonathan Lennox <jonathan@vidyo.com>
To: "Ruediger.Geib@telekom.de" <Ruediger.Geib@telekom.de>
Thread-Topic: ICE might send your traffic over TCP
Thread-Index: AQHPprMFiUVrQpioSUe4c1RT1xtq+puu0UIwgACzvwA=
Date: Thu, 24 Jul 2014 13:00:49 +0000
Message-ID: <008FDAFA-6358-4016-9785-8A2C72CE312E@vidyo.com>
References: <73287998-61BE-4481-B16D-D11F0EA69870@vidyo.com> <CA7A7C64CC4ADB458B74477EA99DF6F502D8EA763B@HE111643.EMEA1.CDS.T-INTERNAL.COM>
In-Reply-To: <CA7A7C64CC4ADB458B74477EA99DF6F502D8EA763B@HE111643.EMEA1.CDS.T-INTERNAL.COM>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [31.133.191.192]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <F0CE2869AF6A964C8611ED48846446EB@vidyo.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dart/5ErYNXNq-oSrlbr17JaFPU74nvc
Cc: "dart@ietf.org" <dart@ietf.org>
Subject: Re: [Dart] ICE might send your traffic over TCP
X-BeenThere: dart@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" <dart.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dart>, <mailto:dart-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dart/>
List-Post: <mailto:dart@ietf.org>
List-Help: <mailto:dart-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dart>, <mailto:dart-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Jul 2014 13:00:56 -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.

On Jul 24, 2014, at 3:54 AM, Ruediger.Geib@telekom.de wrote:

> 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:dart-bounces@ietf.org] On behalf of Jonathan Lennox
> Subject: [Dart] ICE might send your traffic over TCP
> 
> [snip]
> 
> 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
> 
>

v2.23.0 | Report a Bug | By Email