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

[Bob Briscoe <[e-mail]>]

Mirja,

Belated thanks for this.

We will address your comments, hopefully producing a rev this week.


Bob

At 18:38 22/02/2011, 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.
>
>-> 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
>-------------------------------------------------------------------

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design