[e2e] Why do we need congestion control?
l.wood at surrey.ac.uk
Sat Mar 16 18:47:58 PDT 2013
the IETF is not one thing. Did the request to update RFC2309 come from the IESG (currently lacking transport expertise, I see - big fuss on ietf at ietf.org), the IAB, a WG, BOF, or other?
Your update backs away from engineering specifics in favour of generalities; it is very much a political, not an engineering, document. In backing away from recommending RED, it does nothing to fix RED.
and the 'RED in a different light' section down the page for details of bugs in RED.)
For example, your draft concludes:
"Internet routers SHOULD implement some active queue management
mechanism to manage queue lengths,"
but doesn't say how.
Imagine if in 1986 an RFC said:
"Internet hosts SHOULD implement some congestion control mechanism
to manage TCP packet transmission"
and just left it at that. Problem solved!
I am unable to grok why the RFC series specifies TCP congestion control behaviour in minute detail in standards documents, and yet does not do so for router behaviour affecting that selfsame congestion control. (Is this to leave competitive advantage to router manufacturers? Letting the market decide? Because congestion control isn't really that important? No idea.)
Please first document the fixes to RED in a draft intended for RFC publication, and _then_ try updating a document encouraging people to implement it in routers.
I am but an egghead.
From: end2end-interest-bounces at postel.org [end2end-interest-bounces at postel.org] On Behalf Of Fred Baker (fred) [fred at cisco.com]
Sent: 16 March 2013 21:00
To: Srinivasan Keshav
Cc: end2end-interest at postel.org
Subject: Re: [e2e] Why do we need congestion control?
Keshav: Good to hear from you. It's been a while since we chatted.
The IETF has decided that it needs to update RFC 2309, which is a statement from the End-to-End Research Group encouraging vendors and operators to implement AQM, and specifically RED, to cooperate with TCP-and-etc congestion control mechanisms. To that end, I took it upon myself to write a proposed update. At this point, it's literally that, and could use serious review by people who know more about it than I. "I am an egg."
Discussion will be on that list, so I'm inviting folks on end-to-end at postel.org to join it.
aqm at ietf.org
If you do, fair warning: you are now as much a "member" of the IETF as I am.
The document I have posted, and solicit comment on, is
"IETF Recommendations Regarding Active Queue Management", Fred Baker,
AQM will be discussed on this list, and in a BOF (I'm told) at IETF 87 in Berlin next summer.
> From: "Fred Baker (fred)" <fred at cisco.com>
> Subject: Re: [aqm] New Version Notification for draft-baker-aqm-recommendation-00.txt
> Date: March 15, 2013 7:51:43 PM MDT
> To: "aqm at ietf.org" <aqm at ietf.org>
> Somewhat with my heart in my hands, given discussion on this list about text I botched and about RFC 2309's recommendation of RED, I have taken it upon myself to do a wholesale replacement of RFC 2309. I'd appreciate people's comments - especially from the original authors of RFC 2309.
> For comparison and review purposes, you may like to look at a diff from RFC 2309. If so, go to
> and give it two URLs:
>> A new version of I-D, draft-baker-aqm-recommendation-00.txt
>> has been successfully submitted by Fred Baker and posted to the
>> IETF repository.
>> Filename: draft-baker-aqm-recommendation
>> Revision: 00
>> Title: IETF Recommendations Regarding Active Queue Management
>> Creation date: 2013-03-15
>> Group: Individual Submission
>> Number of pages: 17
>> URL: http://www.ietf.org/internet-drafts/draft-baker-aqm-recommendation-00.txt
>> Status: http://datatracker.ietf.org/doc/draft-baker-aqm-recommendation
>> Htmlized: http://tools.ietf.org/html/draft-baker-aqm-recommendation
>> This memo presents recommendations to the Internet community
>> concerning measures to improve and preserve Internet performance. It
>> presents a strong recommendation for testing, standardization, and
>> widespread deployment of active queue management in routers, to
>> improve the performance of today's Internet. It also urges a
>> concerted effort of research, measurement, and ultimate deployment of
>> router mechanisms to protect the Internet from flows that are not
>> sufficiently responsive to congestion notification.
>> The IETF Secretariat
More information about the end2end-interest