Re: [Tsvwg] HEADS UP: consensus call on draft-floyd-tsvwg-cc-alt

Bob Briscoe <rbriscoe@jungle.bt.co.uk> Fri, 02 March 2007 19:15 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 1HNDDw-0005y7-Ur; Fri, 02 Mar 2007 14:15:24 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNDDv-0005xx-6r for tsvwg@ietf.org; Fri, 02 Mar 2007 14:15:23 -0500
Received: from smtp2.smtp.bt.com ([217.32.164.150]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HNDDn-00017S-J6 for tsvwg@ietf.org; Fri, 02 Mar 2007 14:15:23 -0500
Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Mar 2007 19:15:10 +0000
Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Mar 2007 19:15:10 +0000
Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1172862908573; Fri, 2 Mar 2007 19:15:08 +0000
Received: from mut.jungle.bt.co.uk ([10.215.131.59]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id l22JF5St009764; Fri, 2 Mar 2007 19:15:08 GMT
Message-Id: <5.2.1.1.2.20070302184131.02a13170@pop3.jungle.bt.co.uk>
X-Sender: rbriscoe@pop3.jungle.bt.co.uk
X-Mailer: QUALCOMM Windows Eudora Version 5.2.1
Date: Fri, 02 Mar 2007 19:15:11 +0000
To: Sally Floyd <sallyfloyd@mac.com>
From: Bob Briscoe <rbriscoe@jungle.bt.co.uk>
Subject: Re: [Tsvwg] HEADS UP: consensus call on draft-floyd-tsvwg-cc-alt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: -1.36 () ALL_TRUSTED
X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
X-OriginalArrivalTime: 02 Mar 2007 19:15:10.0231 (UTC) FILETIME=[1896F270:01C75CFF]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Cc: tsvwg <tsvwg@ietf.org>, Mark ALLMAN <mallman@icir.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

Sally, Mark,

At 23:12 22/02/2007, Sally Floyd wrote:
>..
>I would leave bullet (2) about "Using Spare Capacity" in.  It was 
>motivated by Quick-Start, whose entire purpose is to
>use spare capacity.  It was also motivated by High-Speed TCP, which had as 
>a motivation using spare capacity.
>I think it is worthwhile that  say that successfully using space capacity 
>is a good thing, but it doesn't eliminate the
>requirement for fairness.

I've been trying to come up with text on spare capacity that better matches 
the absolutely necessary essence in the design of Quickstart, without 
over-constraining future controls. How about this - inspired by Mark's new 
text on bullet (1) (offline)?

============================================================================
(2) Using Spare Capacity.

If alternate congestion controllers send at high rates during times when 
they believe there is no congestion, they always run the risk that traffic 
in flight will cause congestion. Proposed congestion control mechanisms 
that aim to use spare capacity should be evaluated on how they minimise the 
risk of causing severe congestion that will not be seen until at least a 
round trip later.

Similar to point (1), alternate congestion controllers using spare capacity 
that risk a significantly negative impact on traffic using standard 
congestion control may be suspect and this aspect should be part of the 
community's decision making with regards to the suitability of the 
alternate congestion control mechanism.
============================================================================

I wanted to avoid the IETF making any judgement on how spare capacity 
should be divided up. This is a completely open question, that we should 
avoid. The only concern is what might happen if you're driving on an open 
road while snatching short bursts of shut-eye.


Bob



Bob Briscoe,                           Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196