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

From: Bob Briscoe <[email-masked]>
Date: Sun, 08 Nov 2009 17:23:00 +0000

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

---

From: Gorry Fairhurst <[email-masked]>
Date: Sun, 08 Nov 2009 17:39:47 +0000

OK,

Looks to me like we will now need a revised I-D along these lines.

Best wishes,

Gorry

Bob Briscoe wrote:
>> 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.
> 
>> 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.
>>
> Yup. But I think it goes a bit beyond SotA - it brings out conclusions 
> that haven't appeared explicitly elsewhere.
> 
> 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.
> 
> 
> 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.
> 
> 
>> 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.
> 
> 
> 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".
> 
> 
>> 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 
>> 8) I'll review the appendices and security considerations in the next 
>> revision.
> 
> Tx
> 
>