Subject: [Tsvwg] Comments on rev-03: Quick-Start for TCP & IP

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 17 May 2006 16:10:47 +0100

Last time, I said there were a few more comments on the final part of 
Quick-Start for TCP & IP, so here are my comments on rev-03.

best wishes,

Gorry

---
Table 1/Appendix B:  Lowest permitted encoded QS request?

When I thought about the encoding method for QS requests, 80kbps seemed 
logical for TCP, given initial windows and current TCP. Thinking more 
about the mapping and trying to envisage its use with NON-TCP flows, I 
wonder whether the lowest rate of 80 kbps is a factor of two too high?
- I can see cases where UDP/TFRC, DCCP, etc flows could utilise QS to 
raise a congestion window for the same reasons as TCP, but where the 
target rate was much less than 80 kbps. This isn't the same as the 
request for finer resolution (or additional semantics as in DS), it's 
just a check that the set of rates is appropriate to other transports 
after that question was raised.

---
Figure 4 / Section 3.3.1 / 9.4.1 : QS Approved Rate & NONCE.

I note that the QS Approved Rate has no NONCE value in the second row of 
the header. After looking at this, I beleive we can perform additional 
useful checks (at a policer that utilises this message) if the message 
were to include the ORIGINAL nonce value issued by the sender with teh
QS request. The implementation at the sender is simple, senders already 
cache the nonce value to interpret the response. Senders re-issue the 
same NONCE in the Rate Approval message.

Routers processing the Approved message may now choose to match the
NONCE that they first saw (routers do not need to keep state, but if 
they do, they could also cache the NONCE value). If the cached value 
(masked by the rate), matches the Approval (masked by the rate) then it 
is probable this approval is actually for an earlier request. If they do 
not match, then the Approval may be ignored.

This allows routers to associate requests with Approvals, it also 
reduces a new DoS vulnerability, where Approval messages could be
injected by a third party (not on the path). If such Approval messages
were to result in a flow being penalised, it is worth minimising the
risk from bogus messages. The DoS threats for Approval messages now seem
to resemble those for QS requests.

---
Section 13.

This revision seems to have introduced a new section after the IANA 
considerations and before the conclusion. I'd like to question the 
placement of this text. The review of related work is useful context and 
background both to the problem statement and design, but it does not 
seem right to me to have this as a section of the document when the 
appendices also describe a range of issues, historical documents and 
alternative possibilities. This could be seen to give more credibility 
to some approaches than to others (in appendices), which I would have 
hoped could have avoided. Could we move this text to an Appendix?

--- NiTS ---

Page 17, Figure 3 has a blank field after the QS NONCE, I think this
should be marked as "reserved".

Page 18, this lists the various fields, but does noit explain the QS
Nonce - a sentence pointing to section 3.4 would be welcome here.