Re: [Tsvwg] comments wanted: draft-eggert-tsvwg-udp-guidelines

Lars Eggert <lars.eggert@nokia.com> Fri, 09 March 2007 09:28 UTC

Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPbP3-0005LB-2Q; Fri, 09 Mar 2007 04:28:45 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPZXc-00076I-3J for tsvwg@ietf.org; Fri, 09 Mar 2007 02:29:28 -0500
Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPZXa-0004rG-3e for tsvwg@ietf.org; Fri, 09 Mar 2007 02:29:28 -0500
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l297TLaL013585; Fri, 9 Mar 2007 09:29:24 +0200
Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Mar 2007 09:29:09 +0200
Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh103.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Mar 2007 09:29:08 +0200
Received: from [172.21.35.178] (esdhcp035178.research.nokia.com [172.21.35.178]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l297T7W9030975; Fri, 9 Mar 2007 09:29:07 +0200
In-Reply-To: <006e30641e6eef188dfcd7f955a3ff08@mac.com>
References: <E1HM9Gt-0001fP-8L@stiedprstage1.ietf.org> <21B62EB2-7A61-44EA-A346-3C86BCAADD76@nokia.com> <311b45ff3aec752861e167899b6a0842@mac.com> <845E19EA-69FD-44BF-858C-DECBB6BB387B@nokia.com> <006e30641e6eef188dfcd7f955a3ff08@mac.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: multipart/signed; micalg="sha1"; boundary="Apple-Mail-7--302868860"; protocol="application/pkcs7-signature"
Message-Id: <1CC28BAE-A94B-4807-B52D-D7B07441D2F5@nokia.com>
From: Lars Eggert <lars.eggert@nokia.com>
Subject: Re: [Tsvwg] comments wanted: draft-eggert-tsvwg-udp-guidelines
Date: Fri, 09 Mar 2007 09:29:02 +0200
To: ext Sally Floyd <sallyfloyd@mac.com>
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 09 Mar 2007 07:29:08.0983 (UTC) FILETIME=[A035B870:01C7621C]
X-eXpurgate-Category: 1/0
X-eXpurgate-ID: 149371::070309092924-31DA6BB0-494070CD/0-0/0-1
X-Nokia-AV: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5
Cc: tsvwg WG <tsvwg@ietf.org>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org

On 2007-3-7, at 19:47, ext Sally Floyd wrote:
>> I assume you mean DCCP CCID2 by "TCP-like congestion control?"
>>
>> If so, the first paragraph in Section 3 alreadys recommends that  
>> apps use a congestion-controlled protocol instead of UDP, and  
>> points to DCCP.
>>
>> Or am I misunderstanding?
>
> I was just suggesting that in the sentence where you mention TFRC   
> "or otherwise..." as recommended
> action, you also mention TCP-like congestion control, by name.   
> Just to make it clear that it
> TFRC isn't necessarily being recommended over TCP-like congestion  
> control, for the purposes of
> this document.  (If the application is implementing it, it is  
> better called "TCP-like congestion control
> [CCID2]" instead of just "CCID2", I think.  Because CCID2 contains  
> some DCCP-specific stuff that wouldn't
> be included if an application was implementing it itself.)
>
> So:  "TFRC, TCP-like congestion control (as in [CCID2]), or  
> otherwise ensure..."
>
> Does that make sense?

I'm not sure it goes with the flow of the argument. The document says  
in in the first paragraph of Section 3 that apps should really be  
using an existing congestion controlled transport instead of UDP, and  
includes DCCP as an example of what to use (I could point to specific  
CCIDs here).

The rest of Section 3 applies to apps that for some reason chose not  
to use one of the congestion-controlled protocols, including DCCP,  
and instead chose to use UDP. These apps could still implement TFRC  
for UDP.

Is your suggestion to point out that they could also implement a TCP- 
like windowing mechanism instead of TFRC? (In which case calling it  
CCID2 is confusing, because that is tied to the use of DCCP, no?)

Thanks,
Lars