IETF Logo Mail Archive

RE: [tcpm] rfc2581bis-01 and RFC 2861

"Christian Huitema" <huitema@windows.microsoft.com> Mon, 24 July 2006 16:35 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G53P6-0004BT-Ud; Mon, 24 Jul 2006 12:35:36 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G53P5-00043W-Av for tcpm@ietf.org; Mon, 24 Jul 2006 12:35:35 -0400
Received: from mail1.microsoft.com ([131.107.1.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G53P4-0000V4-0M for tcpm@ietf.org; Mon, 24 Jul 2006 12:35:35 -0400
Received: from mailout6.microsoft.com ([157.54.69.150]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Jul 2006 09:35:33 -0700
Received: from tuk-hub-04.redmond.corp.microsoft.com ([157.54.70.30]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Jul 2006 09:35:33 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.69.169]) by tuk-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Jul 2006 09:35:31 -0700
Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.2725); Mon, 24 Jul 2006 09:35:20 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [tcpm] rfc2581bis-01 and RFC 2861
Date: Mon, 24 Jul 2006 09:35:18 -0700
Message-ID: <70C6EFCDFC8AAD418EF7063CD132D064015DE074@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com>
In-Reply-To: <20060724113622.EA6A14410F4@lawyers.icir.org>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [tcpm] rfc2581bis-01 and RFC 2861
Thread-Index: AcavFaCEDyA7RjiSS0a7ofAeO0ej7AAKPP3w
References: <Pine.GSO.4.58.0607240029460.5608@dynasty.cs.columbia.edu> <20060724113622.EA6A14410F4@lawyers.icir.org>
From: Christian Huitema <huitema@windows.microsoft.com>
To: mallman@icir.org, Salman Abdul Baset <salman@cs.columbia.edu>
X-OriginalArrivalTime: 24 Jul 2006 16:35:20.0313 (UTC) FILETIME=[2742D690:01C6AF3F]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Cc: tcpm@ietf.org
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Errors-To: tcpm-bounces@ietf.org

> RFC 2581 bases the reduction of cwnd on FlightSize (amount of
> outstanding data) not cwnd.  So, the CBR over TCP will be reduced by
> half.  I.e., if you have 10 packets outstanding, a cwnd of 100000
> packets and take a loss your new cwnd should be 5 packets.  The notion
> of FlightSize was introduced into the spec. to accommodate cases
> whereby the cwnd does not accurately reflect the load being placed on
> the path.
> (As has been discussed on this list before, this is not an ideal fix
> because it causes issues in another case.)

One may in fact question whether this is even the right thing. Suppose a
1 Mbps link is shared between a 64 kpbs "CBR" flow and a "best effort"
file transfer. The file transfer window will increase until it reaches
something larger than 1 Mbps. A that point, queues will build up, and
eventually some packets will be dropped. You certainly want the file
transfer rate to drop to 512 kbps, and then progressively increase. But
do you really want the CBR flow to drop to 32 kbps? Is that fair? Is
that even useful?

-- Christian Huitema

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm

v2.23.0 | Report a Bug | By Email