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

Mark Allman <mallman@icir.org> Mon, 05 March 2007 14:58 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 1HOEe9-00040j-NC; Mon, 05 Mar 2007 09:58:41 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOEe8-00040d-Mf for tsvwg@ietf.org; Mon, 05 Mar 2007 09:58:40 -0500
Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOEe7-0007Pi-69 for tsvwg@ietf.org; Mon, 05 Mar 2007 09:58:40 -0500
Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l25EwWhe029871; Mon, 5 Mar 2007 06:58:33 -0800
Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 9221F87756B; Mon, 5 Mar 2007 09:58:27 -0500 (EST)
Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 3E3F618F53E; Mon, 5 Mar 2007 09:58:26 -0500 (EST)
To: tsvwg@ietf.org
From: Mark Allman <mallman@icir.org>
Subject: Re: [Tsvwg] HEADS UP: consensus call on draft-floyd-tsvwg-cc-alt
In-Reply-To: <d5562e1a6b1677cebf1a837cf2eeaf92@mac.com>
Organization: ICSI Center for Internet Research (ICIR)
Song-of-the-Day: Dance the Night Away
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_bOundary"; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Mon, 05 Mar 2007 09:58:26 -0500
Message-Id: <20070305145826.3E3F618F53E@lawyers.icir.org>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Cc: Sally Floyd <floyd@icir.org>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: mallman@icir.org
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

Folks-

About this business of fairness.  We had a little thread with Bob
off-list.  We changed the text in the draft a bit to make it more
generic, change the emphasis and remove some specific examples.  Bob has
indicated to us that the changes work for him.

Basically, instead of using 'fairness' as the measuring stick (whatever
that might mean in whatever context) we have said that an alternate
congestion control scheme should present evidence about how it impacts
standard congestion control.  How that is assessed is not specified.

We replaced the bullets on 'fairness' and on 'spare capacity' in the
draft with the text included below.  We would, of course, be open to
comments on the new text.

The TSVWG-00 document should be coming out in the archives, soon.
However, there was a snafu in the posting process.  You can grab the
current version at:

    http://www.icir.org/mallman/papers/draft-ietf-tsvwg-cc-alt-00.txt

allman


    (1) Impact on Standard TCP, SCTP [RFC2960], and DCCP [RFC4340].
    
        Proposed congestion control mechanisms should be evaluated when
        competing with standard IETF congestion control.  Alternate
        congestion controllers that have 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.

	We note that this bullet is not a requirement for strict
	TCP-friendliness as a prerequisite for an alternate congestion
	control mechanism to advance to Experimental.  As an example,
	HighSpeed TCP is a congestion control mechanism that is
	Experimental, but that is not TCP-friendly in all environments.
	We also note that this guideline does not constrain the
	fairness offered for non-best-effort traffic.

        As an example from an Experimental RFC, fairness with standard
<        TCP is discussed in Sections 4 and 6 of RFC 3649 (High-Speed
        TCP) and using spare capacity is discussed in Sections 6, 11.1,
        and 12 of RFC 3649 (High-Speed TCP).