[Dart] ICE might send your traffic over TCP

Jonathan Lennox <jonathan@vidyo.com> Wed, 23 July 2014 20:16 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 0B0B21A0313 for <dart@ietfa.amsl.com>; Wed, 23 Jul 2014 13:16:54 -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 3AXlvQ7C7AIi for <dart@ietfa.amsl.com>; Wed, 23 Jul 2014 13:16:51 -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 9C2FB1B27F2 for <dart@ietf.org>; Wed, 23 Jul 2014 13:16:48 -0700 (PDT)
X-Note-AR-ScanTimeLocal: 7/23/2014 4:16:45 PM
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-196/SG:2 7/23/2014 4:16:16 PM
X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.934255 p=-0.968577 Source White
X-Signature-Violations: 0-0-0-3134-c
X-Note-419: 15.6007 ms. Fail:0 Chk:1335 of 1335 total
X-Note: SCH-CT/SI:0-1335/SG:1 7/23/2014 4:16:40 PM
X-Note: Spam Tests Failed:
X-Country-Path: ->UNITED STATES->
X-Note-Sending-IP: 162.209.16.213
X-Note-Reverse-DNS: mail1.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 141768977 for dart@ietf.org; Wed, 23 Jul 2014 16:16:45 -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; Wed, 23 Jul 2014 15:16:44 -0500
From: Jonathan Lennox <jonathan@vidyo.com>
To: "dart@ietf.org" <dart@ietf.org>
Thread-Topic: ICE might send your traffic over TCP
Thread-Index: AQHPprMFiUVrQpioSUe4c1RT1xtq+g==
Date: Wed, 23 Jul 2014 20:16:44 +0000
Message-ID: <73287998-61BE-4481-B16D-D11F0EA69870@vidyo.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [31.133.187.197]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <658218C87F55054B94114C64968A6EFB@vidyo.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dart/aYlocfQBZcB8qPASYt3u9Q6052s
Subject: [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: Wed, 23 Jul 2014 20:16:54 -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