[tsvwg] Comments on draft-ietf-tsvwg-byte-pkt-congest-01.txt (Oct 2009)

[Gorry Fairhurst <gorry at erg.abdn.ac.uk>]

Revived I-D: draft-ietf-tsvwg-byte-pkt-congest-01.txt

Bob,

I've been reading the recently revived draft. We seemed to have good 
consensus to update the recommendations for using byte and packet mode 
in the network for congestion notification.

I thought I had previously sent some top-level comments, but alas these 
seem to have gone amiss, so I'll combine my notes with a review of the 
current rev. This makes for a longer than normal set of comments, sorry. 
As usual, I have split top-level and editorial comments.

1) My summary is that most of the text is a summary review of the 
current state of the art. The aim is to clarify the implications of 
congestion reporting and then to make appropriate conditions for future 
work. Has the text been published in a technical paper?

2) There are important conclusions at the end, these are simple (as 
presented in an earlier TSVWG meeting) - but the current standards 
section seem to need some additional work to get the standards language 
correct and make sure they represent IETF consensus and not just the 
author's viewpoint.

3) There seems to be a need for some additional work to provide concrete 
recommendations on: "How to handle any legacy of AQM with byte-mode drop 
already deployed;" (section 7.1).

4) The text seems to use both "byte" and "bits" as measures of capacity, 
it could be better to just use bytes, perhaps, to be consistent with the 
language of RED.

5) Throughout the document there is reference to a survey. Is this 
survey performed outside the IETF? Does the WG know what was asked and 
how are we to understand the returns? I think we need to see the best 
way to include this survey detail.

6) I personally found the use of "resource" as an abstraction that made 
it harder to reader - rather than easier. (I wondered whether this was 
more suited to a scientific paper than a standards update?).

7) I think it could be nice to see a short section on middlebox/firewall 
implications. To me, the document would have been clearer if the core of 
the document focussed on AQM/RED in routers and then explicitly had a 
section for middleboxes, and whatever else that addresses the 
implications in these cases. I don't anticipate middlebox and 
applications developers parsing through the whole document to see what 
they should do.

8) I'll review the appendices and security considerations in the next 
revision.

9) Overall, I found the body of the current text to be quite hard to 
parse and many of my detailed comments relate to these aspects.  I 
suggest this still needs editorial work to distill this to the point at 
which it would be ready to get detailed comments on the recommendations 
from the WG.

Best wishes,

Gorry