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

Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 24 July 2014 21:18 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 ACFC71A0880 for <dart@ietfa.amsl.com>; Thu, 24 Jul 2014 14:18:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
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 zoPFtzWwWlsf for <dart@ietfa.amsl.com>; Thu, 24 Jul 2014 14:18:51 -0700 (PDT)
Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id B1B331A0146 for <dart@ietf.org>; Thu, 24 Jul 2014 14:18:50 -0700 (PDT)
Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta08.westchester.pa.mail.comcast.net with comcast id WM7j1o0020mv7h058MJqMU; Thu, 24 Jul 2014 21:18:50 +0000
Received: from dhcp-a57b.meeting.ietf.org ([31.133.165.123]) by omta11.westchester.pa.mail.comcast.net with comcast id WMGg1o00S2g3ukn3XMGkJU; Thu, 24 Jul 2014 21:16:48 +0000
Message-ID: <53D177B8.7030500@alum.mit.edu>
Date: Thu, 24 Jul 2014 17:16:40 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: dart@ietf.org
References: <73287998-61BE-4481-B16D-D11F0EA69870@vidyo.com> <CA7A7C64CC4ADB458B74477EA99DF6F502D8EA763B@HE111643.EMEA1.CDS.T-INTERNAL.COM> <008FDAFA-6358-4016-9785-8A2C72CE312E@vidyo.com> <8538E3A9-6AFC-4A53-89EB-76DEB4C559C8@nostrum.com>
In-Reply-To: <8538E3A9-6AFC-4A53-89EB-76DEB4C559C8@nostrum.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1406236730; bh=LqMJp+oADSRxqbU5A7looWURcFonj78lTReFJ5K1Cbg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=DBLoMhKJyM0+yESr52mczT6N3TEbPUsyhcrSG3waFlauDu0Z8WzdabcJj7NcxqSTx uY1FeurktmLgAhWtMUiBSKDXRQxiIg9Kk2tdHYf/qe/vkfkY/vZqAfTeR7MAkLDmRK 7qxeh/1Du2Xo60GdClx3rwys+1r6RKVGWDgL2mwn/VqT5NzMCQtMvhVs+hJ47IpKEU ZIhm6+ATHq7XpEiMRsqKJX5koDKQv2dVUvUkKtbRiXyZShdoPiKylcZLtTShrKTYXL 3cp37i6OZdfZRRNZXyqVdNGG4D57qFNmzf096JY2X/mQzNdpazGC9pR0EOJamxkqNC KyoBCUkuU7pjg==
Archived-At: http://mailarchive.ietf.org/arch/msg/dart/4kI3QxUGIQAS44tRGnf-bx-aIEY
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 21:18:51 -0000

On 7/24/14 3:44 PM, Ben Campbell wrote:
> (as individual)
>
> On Jul 24, 2014, at 9:00 AM, Jonathan Lennox <jonathan@vidyo.com> wrote:
>
>> 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.
>>
>
> 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?

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

	Thanks,
	Paul