[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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...

At 15:52 23/10/2009, Eddy, Wesley M. (GRC-MS00)[Verizon] wrote:

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"?


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


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 cngestion
notification into the wire protocol" and "Inferring congestion and
decoding congestion notification from the wire".
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?). 
=============================================================================


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.
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)
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.
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...



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.


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. 


- 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.
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



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:rbriscoe at jungle.bt.co.uk]
>Sent: Friday, October 23, 2009 12:12 AM
>To: Joe Touch; Eddy, Wesley M. (GRC-MS00)[Verizon]; Jukka MJ Manner
>Cc: tsvwg at ietf.org
>Subject: Re: [tsvwg] I-D Action:draft-ietf-tsvwg-byte-pkt-congest-01.txt
>
>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, Internet-Drafts at ietf.org 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
>>         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.
>>
>>
>><ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-byte-pkt-cong est->01.txt> 
>
>________________________________________________________________
>Bob Briscoe,                                BT Innovate & Design


________________________________________________________________
Bob Briscoe, BT Innovate & Design