Re: I-D Action:draft-ietf-tsvwg-byte-pkt-congest-03.txt

Colin Perkins <> Wed, 10 November 2010 06:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 082BC3A68F0 for <>; Tue, 9 Nov 2010 22:20:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.57
X-Spam-Status: No, score=-103.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YcJ4EFuXWcWD for <>; Tue, 9 Nov 2010 22:20:37 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 96D183A68F8 for <>; Tue, 9 Nov 2010 22:20:27 -0800 (PST)
Received: from ([]) by with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1PG434-0005Ws-p8; Wed, 10 Nov 2010 06:20:47 +0000
Subject: Re: I-D Action:draft-ietf-tsvwg-byte-pkt-congest-03.txt
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Colin Perkins <>
In-Reply-To: <>
Date: Wed, 10 Nov 2010 14:20:40 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Jukka Manner <>
X-Mailer: Apple Mail (2.1081)
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 10 Nov 2010 06:20:51 -0000


I've read this draft, and find it improved over the previous version, since it makes it easier to find the recommendations.

The recommendation in section 3.1 on how to measure congestion is clear.

I don't entirely understand the recommendation in section 3.2: this makes it clear what the network should not do, but doesn't really help on what it should do. I'd find the draft easier to understand if it said "when notifying congestion, a network device SHOULD...".

If I understand the recommendation in section 3.3 correctly, it could be phrased as "a transport protocol SHOULD take into account the fraction of bytes that indicate congestion when determining its sending rate, rather than the fraction of packets indicating congestion". If this is correct, I'd find a more active phrasing of what the transport should do, such as this, to be clearer. 

The reason I first looked at this draft was to get some guidance on how to design the extensions for ECN running on RTP over UDP. One of the more difficult design choice for that protocol is how to handle ECN processing in middleboxes that transparently split or combine packets. We originally chose to follow RFC 3168 for this, but have recently received guidance to take into account packet size. That guidance doesn't obviously follow from this draft, since the draft focusses on end-to-end transports reading congestion indications, not in-network middleboxes. Some clarification on which aspects of these recommendations are appropriate for middleboxes would be helpful.


On 27 Oct 2010, at 17:57, Jukka Manner wrote:
> Dear all,
> Bob and I did our best to enhance the readability of the draft and make the recommendations more clear. Please check the draft and comment on the clarity and structure of the presentation. We are hoping to get to WGLC soon.
> Note that I have held Bob back in cutting text out, in order to document the issues as well as possible, to have a place where the issue is discussed in depth (instead of emails on some mailing list). Therefore the draft has not become shorter but hopefully more clear.
> Regards,
> Jukka
> On 10/26/2010 01:15 AM, wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Transport Area Working Group Working Group of the IETF.
>> 	Title           : Byte and Packet Congestion Notification
>> 	Author(s)       : B. Briscoe, J. Manner
>> 	Filename        : draft-ietf-tsvwg-byte-pkt-congest-03.txt
>> 	Pages           : 41
>> 	Date            : 2010-10-25
>> This memo concerns dropping or marking packets using active queue
>> management (AQM) such as random early detection (RED) or pre-
>> congestion notification (PCN).  We give three strong recommendations:
>> (1) packet size should be taken into account when transports read
>> congestion indications, (2) packet size should not be taken into
>> account when network equipment creates congestion signals (marking,
>> dropping), and therefore (3) the byte-mode packet drop variant of the
>> RED AQM algorithm that drops fewer small packets should not be used.
>> A URL for this Internet-Draft is:
>> Internet-Drafts are also available by anonymous FTP at:
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.

Colin Perkins