[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [tsvwg] Comments on draft-ietf-tsvwg-byte-pkt-congest-01.txt (Oct 2009)
Gorry,
Sorry for delayed reply and thanks again for another conscientious review.
At 11:52 26/10/2009, Gorry Fairhurst wrote:
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 think we should check for technical consensus - I tried to
accomodate Fred Baker's concerns, so it would be nec to see if I have.
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.
Yup. But I think it goes a bit beyond SotA - it brings out
conclusions that haven't appeared explicitly elsewhere.
Has the text been published in a technical paper?
Nope - but I ought to submit a variant to a journal, to get reesarch
community review.
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
I admit, having read it through again recently, it is a bit rambling
and needs the main points brought out and the weeds cutting back.
and make sure they represent IETF consensus and not just the
author's viewpoint.
Yes - see above.
Note that it effectively suggests that we need to be catering for
packet size in transports beyond TCP.
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).
I know we can't be certain there isn't any, but over the months I
still haven't detected a sniff of any of this being ever implemented,
except in ns2.
I think the best and most practical approach is to say that
transports should be designed assuming there is no byte-mode drop in
the network. It sort of says that already, so I should make it clear.
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.
OK
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.
There were constraints on revealing the details of the survey,
because it involved questions about the DoS vulnerability and was
conducted by a security organisation - therefore offering respondents
anonymity. I'll see if I can be a little less circumspect without
breaking any agreements.
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?).
After briscoe-01 a comment asked that it should be generalised from
routers to AQM in any queue at any layer, including in middleboxes.
So I definitely don't want to say router.
But I will be more explicit about this generalisation early on so
people understand why it sounds so abstract. The only other useful
words I know for resource are "forwarding element" or "queue".
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.
I don't believe the implications are any different between routers &
middleboxes - they should all use pretty much the same AQM.
8) I'll review the appendices and security considerations in the
next revision.
Tx
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.
Definitely. I found it hard to read myself.
Bob
Best wishes,
Gorry
________________________________________________________________
Bob Briscoe, BT Innovate & Design