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

[Bob Briscoe <[e-mail]>]

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

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

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

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



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

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

>>Also I don't know
>>why the 2. corollary says "If RED is used" because this is true for all queue
>>measurements.

PCN != RED
DCTCP != RED.

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

I think this is a better way round.

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

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.


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

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

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

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.



>>->  4. A Survey and Critique of Past Advice
>>------------------------
>>    - 4.1.: 1. paragraph: Do you have the respective reference?
>
>[JM]: Will try to find something.

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


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

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



>>->  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.
>>
>>
>
>________________________________________________________________
>Bob Briscoe,                                BT Innovate & Design