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

[Mirja Kuehlewind <[e-mail]>]

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. 

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

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

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

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

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

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

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

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

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

-> 4. A Survey and Critique of Past Advice
------------------------
  - 4.1.: 1. paragraph: Do you have the respective reference?
  - 4.2.3.: 1.paragraph: "... these two proposal are safer and ..." Why are 
they safer?
  - 4.2.3.: 2.paragraph: Doesn't this give a new option for attacks?

-> Would move 4.2.5. to Appendix

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

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



-- 
-------------------------------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Institute of Communication Networks and Computer Engineering (IKR)
University of Stuttgart, Germany
Pfaffenwaldring 47, D-70569 Stuttgart

tel: [phone]
email: [e-mail]
web: www.ikr.uni-stuttgart.de
-------------------------------------------------------------------