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

From: Bob Briscoe <[email-masked]>
Date: Wed, 09 Mar 2011 13:47:10 +0000

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 [email-masked] 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: +49(0)711/685-67973
>email: [email-masked]
>web: www.ikr.uni-stuttgart.de
>-------------------------------------------------------------------

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: Jukka Manner <[email-masked]>
Date: Thu, 10 Mar 2011 23:13:30 +0200

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

cheers,
Jukka

> not be intresting for somebody how really wants a recommendation. Maybe move

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

> again... as the doc is anyway quite long, maybe there is an option to shorten

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

> ->  1. Introduction

[JM]: Will rephrase.

>      Reference to RFC 3465 - TCP Congestion Control with Appropriate Byte

[JM]: Sure, will add.

> Motivating Arguments after the recommendation section itself.

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

>       Would move the whole section to the appendix...

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

> rate reduction			300k			12k			
> - The rates are not the link capacity but the transmission rates if sufficient
> - The RED queue would just operate in a certain state with 25% and 1% drop but

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

> ->  3. Recommendations

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

> this statement earlier more explicit.

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

>
>    - 3.3. Both corollaries basically say if modifications are needed because of

[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

[JM]: Will try to find something.

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

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

> side effects makes the doc hard to read and it's hard to focus on the

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

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 11 Mar 2011 11:29:49 +0000

Mirja, Jukka,

Thanks Mirja for this review.

I've said nothing where I agree, and added responses where necessary. Inline...

At 21:13 10/03/2011, Jukka Manner wrote:
>[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.
>
>>

TCP ABC seems superficially relevant here, but it's not actually 
really relevant. On balance I would not add it here.

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

I'd suggest "Why now" would be best at the end of "Motivating 
Arguements", which as a whole would be better after the Recommendations.

>>      The 2. paragraph says the same than the 2. corollary.

Para 2 makes a general statement, whereas corollary 2 is specific to 
the buzz-words used in RED.

>>Also I don't know
>>measurements.

PCN != RED
DCTCP != RED.

>>This paragraph should be the first collary and for the other

I think this is a better way round.

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

Tough. If we shift it to before the Corollaries, it means we have to 
say why we're saying it. I've got no problems with leaving it where it is.

>>and MUST never been done in any layer below.

The recommendations are stated in abstract terms, and the corllaries 
say what this means for specific popular protocols.

>others' behavior. Just have to hope everybody behaves alike (in a good way). :)

Yes. The message here is that no-one in the network layer seems to be 
doing differently from our earlier recommendation. So documenting it 
now might actually mean we have a useful standard behaviour that we 
can rely on.

>[JM]: Will try to find something.

Only BytePktEmail (?!!!) and no-one contradicting it later.

>[JM]: The point about favoring small packets within the network, 
>which was deemed bad since the introduction.
>
>environments, and you have to take that into account if you want to 
>use DSCPs for triggering a certain response from the network.
>
>>
>current appendix material, so would like to keep them within the 
>main body of the doc.

Hopefully, putting the Recommendations up front (and in the 
conclusions) allows people to get the idea quickly. But the rest of 
the info needs to be in the doc for those who want/need specific 
advice for their particular scenario.

Bob