Re: [TERNLI] Notes from tonight's ad hoc

Lars Eggert <lars.eggert@netlab.nec.de> Thu, 03 August 2006 07:57 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8Y5Q-0003XW-7H; Thu, 03 Aug 2006 03:57:44 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8Y5P-0003XR-9E for ternli@ietf.org; Thu, 03 Aug 2006 03:57:43 -0400
Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8Y5N-0007zW-OT for ternli@ietf.org; Thu, 03 Aug 2006 03:57:43 -0400
Received: from localhost (localhost.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 50B4920031E1; Thu, 3 Aug 2006 09:58:04 +0200 (CEST)
Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11061-05; Thu, 3 Aug 2006 09:58:04 +0200 (CEST)
Received: from venus.office (europa.netlab.nec.de [10.1.1.25]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 30E8B20031DB; Thu, 3 Aug 2006 09:58:04 +0200 (CEST)
Received: from n-eggert.office ([10.1.1.112]) by venus.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Aug 2006 09:57:40 +0200
Received: from [127.0.0.1] (localhost [127.0.0.1]) by n-eggert.office (Postfix) with ESMTP id 4B6551704EC; Thu, 3 Aug 2006 09:57:38 +0200 (CEST)
In-Reply-To: <5.2.1.1.2.20060802212808.018d68a0@pop3.jungle.bt.co.uk>
References: <44D0B465.7060902@isi.edu> <20060728125608.670AF444391@lawyers.icir.org> <94176DAD-C2FC-4018-8A15-005606394435@isi.edu> <44D0B465.7060902@isi.edu> <5.2.1.1.2.20060802212808.018d68a0@pop3.jungle.bt.co.uk>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-30-190997617; protocol="application/pkcs7-signature"
Jabber-Id: lars.eggert@jabber.netlab.nec.de
Message-Id: <98BAB2D5-E31B-4240-BCE8-D4A3CC56FF0F@netlab.nec.de>
From: Lars Eggert <lars.eggert@netlab.nec.de>
Subject: Re: [TERNLI] Notes from tonight's ad hoc
Date: Thu, 3 Aug 2006 09:57:36 +0200
To: Bob Briscoe <rbriscoe@jungle.bt.co.uk>
X-Mailer: Apple Mail (2.752.2)
X-OriginalArrivalTime: 03 Aug 2006 07:57:40.0291 (UTC) FILETIME=[7E2D1930:01C6B6D2]
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office)
X-Spam-Score: 0.1 (/)
X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f
Cc: Aaron Falk <falk@ISI.EDU>, ternli@ietf.org
X-BeenThere: ternli@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport-Enhancing Refinements to the Network Layer Interface <ternli.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ternli>, <mailto:ternli-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ternli>
List-Post: <mailto:ternli@ietf.org>
List-Help: <mailto:ternli-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ternli>, <mailto:ternli-request@ietf.org?subject=subscribe>
Errors-To: ternli-bounces@ietf.org

Hi,

On Aug 2, 2006, at 22:29, Bob Briscoe wrote:
> We certainly know what info the *congestion control* part of the  
> transport needs: congestion and delay. So for that we merely need  
> to signal the information the transport needs in packets. And if  
> either of these values changes, it's obvious it's changed. Surely  
> the transport doesn't then need a "something's changed" message.

actually, it's not that obvious. Yes, the transport eventually learns  
that things have changed based on its ongoing path probing, but that  
may be several RTTs later, during which it has transmitted at a rate  
based on stale state. Furthermore, its reaction to the change may be  
too conservative (not a big issue) or not conservative enough.

> Surely the problem is that the netwk layer doesn't signal  
> congestion information with enough precision for the modern  
> transport's needs.

It's not only congestion, it's also delay, plus maybe additional  
information. One work item from the ad hoc meeting was to figure out  
which kinds of information transports do or could operate on.

> My personal preference is to keep the DoS-resistant model...

<I need to think about the snipped parts more.>

> Basically, I'm saying
> a) Instead of signalling "something's changed", I believe it is  
> more practical to continuously signal the "something".

That's an interesting observation. By constantly providing the raw  
information, it is up to the transports to decide what difference  
constitutes a "change" vs. having the network layer decide that a  
"change" has occurred. It also allows transports to process the raw  
information into events any way they see fit, instead of assuming one  
specific way at the layer below.

> b) What congestion control needs most is greater precision for the  
> congestion signal
> c) There are strong but subtle reasons for using probability as a  
> universal congestion signal that lead to overall simplicity when  
> the whole picture is taken into account (which we lose if we adopt  
> QS or XCP).

Lars
-- 
Lars Eggert                                     NEC Network Laboratories