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

[Jukka Manner <[e-mail]>]

Hi Mirja, thanks for the review. I'll comment on your feedback below.

cheers,
Jukka

On 02/22/2011 08:38 PM, Mirja Kuehlewind wrote:
> Hi,
>
> I reviewed the doc. Here are comments:
>
> ->  I haven't read the previous version but I still find the doc quite hard to
> read. I would prefer to have the recommendation right after the introduction
> and all kind of reasoning afterwards. The whole section "1.2 Why now?" might
> not be intresting for somebody how really wants a recommendation. Maybe move
> it to the appendix.

[JM]: I see this as important motivation. It is partly the same as in 
the introduction, so one option is to merge part of it with the main 
intro. I'd rather not put it away in the end.

>
> ->  You mention this mail [pktByteEmail] at least 4 times at different places.
> After a while I really got annoyed reading the same things over and over
> again... as the doc is anyway quite long, maybe there is an option to shorten
> this.

[JM]: Well, it is an important reference. :)

>
> ->  1. Introduction
> ------------------
>    - page 6, 1. paragraph:
>      "However, there are ways of addressing these issues at the transport
>      layer, rather than reverse engineering network forwarding to fix the
>      problems of one specific transport."
>      At this point in the doc it is not clear if the network is reverse
> engineering the transport or vice versa...

[JM]: Will rephrase.

>
>    - page 6, 4 paragraph:
>      Reference to RFC 3465 - TCP Congestion Control with Appropriate Byte
> Counting (ABC)?

[JM]: Sure, will add.

>
>    - page 6, 3. paragraph:
>      Maybe have a brief list with the arguments described in 2. Motivating
> Arguments. I would say, if somebody is reading the doc to get some
> recommendations he would like to hear some arguments right at the beginning
> but having the full discussion is not necessary. That's why I would move 2.
> Motivating Arguments after the recommendation section itself.

[JM]: Switching 2 & 3 could potentially work... I understand your point.

>
>    - 1.2. Why now:
>       Its 2. and 3. the same?
>       Would move the whole section to the appendix...

[JM]: Yes, pretty much, will remove the second one.

>
> ->  2. Motivating Arguments
> ------
>    - 2.3. page 12, 2. paragraph
>      From my point of view does this example give the main reason why
> packet-mode drop is the right thing to do and all other points just support
> this with examples showing that either byte-mode drop is wrong or packet-size
> congestion control would be the easier solution. But the example is
> complicated to read and the reason itself is never clearly stated: Network
> should provide the same behavior against all flows (in this case the same
> rate reduction) independent of their higher level characteristics!
> I would include this example in the introduction and maybe a table like this
> might help (?):
> Packet Size			1500B		60B
> # of packet per 1.2 sec	100			2500
> drop probability		25%			1%
> # of drops			25			25
> rate reduction			300k			12k			
> With the first reading I was confused because the example says XX% of packets
> drops. But as there is a different number of packet in the same time, this
> equals XX% of bits dropped. Maybe this table is a way to make this more
> explicit and thus easier to read (or maybe its just me....). Moreover, you
> could include a picture like this:
>
> 1 Mbps ---------|	25%		|----------750 kbps
> 			|	RED		|
> 1 Mbps............	|	1%		|.............990 kbps
>
> Further remarks on the example to make thing clearer:
> - The rates are not the link capacity but the transmission rates if sufficient
> link capacity is available.
> - The RED queue would just operate in a certain state with 25% and 1% drop but
> whenever RED is dropping packets the one probability will be 25 times larger
> than the other.
> - This is the troughput not the goodput. Thus header overhead it not taken
> into account.

[JM]: I'll rephrase the example to make it hopefully more clear.

>
> ->  3. Recommendations
> -----------------
>    - 3.1. Recommendations on Queue Measurement
>      The 2. paragraph says the same than the 2. corollary. Also I don't know
> why the 2. corollary says "If RED is used" because this is true for all queue
> measurements. This paragraph should be the first collary and for the other
> one I would suggest to rephrase to:
> "An Admin SHOULD NOT be able to configure the way a queue measures itself,
> because wether a queue is bit-congestible or packet-congestible is a property
> of the resource."
> Maybe add an example here.

[JM]: Rephrased the 2. collary, not sure your proposal would make the 
whole recommendation really more clear.

>
>    - 3.2. page 14, 4. paragraph NOTE WELL
>      This is important for understanding the whole wording
used. Maybe make
> this statement earlier more explicit.

[JM]: Any suggestion what/where to put?

>
>    - 3.3. Both corollaries basically say if modifications are needed because of
> layer-specific characteristics, those changes MUST be done in the same layer
> and MUST never been done in any layer below.
> But the question left open here is: If the network is doing the wrong thing
> and I can't know what the network is doing, how can I do the right thing
> (e.g. to get equal rates)?

[JM]: You can only affect how you behave, you can't really affect 
others' behavior. Just have to hope everybody behaves alike (in a good 
way). :)

>
> ->  4. A Survey and Critique of Past Advice
> ------------------------
>    - 4.1.: 1. paragraph: Do you have the respective reference?

[JM]: Will try to find something.

>    - 4.2.3.: 1.paragraph: "... these two proposal are safer and ..." Why are
> they safer?

[JM]: The point about favoring small packets within the network, which 
was deemed bad since the introduction.

>    - 4.2.3.: 2.paragraph: Doesn't this give a new option for attacks?

[JM]: DiffServ only works in practice in closely controlled 
environments, and you have to take that into account if you want to use 
DSCPs for triggering a certain response from the network.

>
> ->  Would move 4.2.5. to Appendix

[JM]: Not yet. ;)

>
> ->  Even though section 4. and 5. are intresting to read, I would see this doc
> as a guideline for implementers or transport designers. Some point are more
> about open research issues. Maybe there is a way to shorten these parts (or
> to move them into a second doc...). Maybe have something like implementor's
> guidelines or design principles instead. Allover the message of the doc is
> (more or less) quite simple but the long discussions on various different
> side effects makes the doc hard to read and it's hard to focus on the
> actually statement.

[JM]: IMO, Sections 4 & 5 are more concrete and important than the 
current appendix material, so would like to keep them within the main 
body of the doc.

>
> ->  I like the conclusion!
>
> Mirja
>
>
> On Tuesday 26 October 2010 00:15:32 [e-mail] 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:
>> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-byte-pkt-congest-03.tx
>> t
>>
>> 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.
>
>
>