Subject: [tsvwg] I-D Action:draft-ietf-tsvwg-byte-pkt-congest-01.txt

From: [email-masked]
Date: Thu, 22 Oct 2009 20:45:02 -0700 (PDT)

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
	Filename        : draft-ietf-tsvwg-byte-pkt-congest-01.txt
	Pages           : 37
	Date            : 2009-10-22

This memo concerns dropping or marking packets using active queue
management (AQM) such as random early detection (RED) or pre-
congestion notification (PCN).  The primary conclusion is that packet
size should be taken into account when transports read congestion
indications, not when network equipment writes them.  Reducing drop
of small packets has some tempting advantages: i) it drops less
control packets, which tend to be small and ii) it makes TCP's bit-
rate less dependent on packet size.  However, there are ways of
addressing these issues at the transport layer, rather than reverse
engineering network forwarding to fix specific transport problems.
Network layer algorithms like the byte-mode packet drop variant of
RED should not be used to drop fewer small packets, because that
creates a perverse incentive for transports to use tiny segments,
consequently also opening up a DoS vulnerability.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-byte-pkt-congest-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 23 Oct 2009 05:12:06 +0100

Joe, Wes, Jukka,

Way back when, I asked James/Magnus if I could let this one slip for 
a while (and dealing with random slaughter at BT Research over the 
last few months has kept my eyes off the ball longer than I thought 
then). But I've just revved it so it's back in circulation.

When it first moved to WG item, you guys volunteered to do a WG last 
call review. I don't think it should be last call yet as I'm sure 
there's some pent-up discussion still to have on it.

But it would be good if at least one of you could take a look as it 
stands and perhaps start that discussion on this list...

Cheers

Bob

At 04:45 23/10/2009, [email-masked] wrote:
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-byte-pkt-congest-01.txt>

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <[email-masked]>
Date: Fri, 23 Oct 2009 09:52:23 -0500

Overall, this is an excellent description of some issues and
presentation of implementation & operational advice that hasn't ever
existed in a concrete form before.  Section 6 is particularly
valuable.

On page 5, do we really mean "SHOULD" or just "should"?

On page 6, it seems like "Coding congestion notification into the wire
protocol" and "Decoding congestion notification from the wire" are
actually "Reacting to congestion, including coding congestion
notification into the wire protocol" and "Inferring congestion and
decoding congestion notification from the wire".

On page 12, section 3 "Working Definition of Congestion Notification"
seems a little too colorful :).  I think the first two sentences can
be eliminated to increase the SNR.  Also the "cannot (or would not)
serve" seems better phrased as "is either incapable of serving in
the short-term or unwilling to serve in the long-term".  What do you
think?  If changed, this would require rephrasing the first part of
the next sentence slightly.

I think that from the perspective of a researcher, the size of the
document is just fine, but as a guy worried about his implementation,
I'd like to see a concise bulleted-list of what I'm supposed to do,
so I can pay attention to that and worry about the text if I have
questions.  These would be something like:

- Implementations of RED and other AQM algorithms SHOULD NOT use the
  "byte-mode" drop.
- Operators SHOULD NOT use "byte-mode" drop settings if these are
  available, but SHOULD still use AQM per RFC 2309
- Implementations and Operators MAY use byte-mode queue measurement
  settings, and SHOULD use these settings rather than packet-modes
  when the congestible resources are directly traceable to a number
  of bits or bytes rather than a number of packets.
- Transport endpoint implementations of ECN, PCN, and other congestion
  notification techniques SHOULD make use packet sizes related to
  congestion notifications, when this information is available.

I'd think putting these in the Introduction and Conclusions would be
a good idea.  It's basically the Cliffs Notes for people who want to
do the right thing without parsing the whole document.  It's also
something that we can reference more easily in things like formal
requirements and interface configuration documents.

I haven't parsed the Appendices yet myself ...

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------

>-----Original Message-----
>From: Bob Briscoe [mailto:[email-masked]]
>Sent: Friday, October 23, 2009 12:12 AM
>To: Joe Touch; Eddy, Wesley M. (GRC-MS00)[Verizon]; Jukka MJ Manner
>Cc: [email-masked]
>Subject: Re: [tsvwg] I-D Action:draft-ietf-tsvwg-byte-pkt-congest-01.txt
>
>Joe, Wes, Jukka,
>

---

From: Bob Briscoe <[email-masked]>
Date: Sat, 24 Oct 2009 00:04:12 +0100

Wes,

Thanks for your kind words and quick response.

I wholeheartedly agree with your idea of having a more concise 
summary of what the draft recommends, in both introduction & conclusions.

In fact, when I read it through myself, I thought there were a number 
of places where I could useful shift text to an appendix (or delete 
it) to make it briefer.

Next rev, I'll try to have a good bash at crisping it up. But I 
decided not to spend that time at this stage, as we need to check if 
there are any substantive disagreements with the message itself. 
There's no point finessing the words before we've agreed what it 
should say in principle.

inline...

>On page 5, do we really mean "SHOULD" or just "should"?

You're right - it's too vague to be a SHOULD (assuming you mean p6, not p5).

>actually "Reacting to congestion, including coding cngestion

Your comment might imply I've not made this clear, as I can't work 
out why you're saying this. Surely the reacting is done by the 
transport after decoding. I'll re-write it as below - is that better?

=============================================================================
Measuring congestion
     When the congested resource decides locally how to measure how 
congested it is. (Should the queue measure its length in bytes or packets?);

Coding congestion notification into the wire protocol:
     When the congested resource decides whether to notify the level 
of congestion on each particular packet. (When a queue considers 
whether to notify congestion by dropping or marking a particular 
packet, should its decision depend on the byte-size of each packet in 
question?);

Decoding congestion notification from the wire protocol:
     When the transport interprets the notification in order to 
decide how much to respond to congestion. (Should the transport take 
into account the byte-size of each missing or marked packet?).
=============================================================================

>be eliminated to increase the SNR.

How about, at least keeping 3 introductory words: "For this 
document,  congestion notification is..."

"For this document", lowers the stakes so we don't need to reach 
consensus on a definition that is *the* definition.

>Also the "cannot (or would not)

Don't like the short-term / long-term bit, but I like the incapable / 
unwilling distinction.

How about just "...is either incapable of serving or unwilling to serve"?

Reason: Even if you set a threshold lower than the actual limit, you 
are no more willing to serve excess load in the short-term than the long-term.
[Perhaps you're trying to allude to something about RED's smoothing, 
but I don't think that's relevant here?]

I've also realised that virtual capacity isn't correct for RED, it's 
a virtual limit to the queue length, not the link capacity (which 
only applies to PCN). So here's the resulting text I propose:

"...Congestion notification is a changing signal that aims to 
communicate the ratio E/L. E is the instantaneous excess load offered 
to a resource that it is either incapable of serving or unwilling to 
serve. L is the instantaneous offered load.

The phrase `unwilling to serve' is added, because AQM systems (e.g. 
RED, PCN) set a virtual limit smaller than the actual limit to the 
resource, then notify when this virtual limit is exceeded in order to 
avoid congestion of the actual capacity.
"

more...

>   of bits or bytes rather than a number of packets.

Actually, I recommend that
"Whether an implementation measures its queue in bytes or packets 
depends on the particular way it is implemented. Implementations 
SHOULD NOT give operators a choice over whether queue measurement is 
in bytes or packets, because the facts of a given implementation will 
determine which it should use.

>requirements and interface configuration documents.

Thoroughly agree - as said above, I'll do this when we've seen if 
there's any disagreement on the list. Thank you.

Cheers

Bob

> >><ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-byte-pkt-cong 
> est->01.txt>
> >