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

From: Sally Floyd <[email-masked]>
Date: Wed, 24 May 2006 21:34:46 -0700

Gorry -

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

Many thanks. 

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

Good question.

Let's assume that no apps need to send small packets more frequently
than every 20 ms.  RFC 3390 pretty much takes care of the needs of
a flow with a 100 ms RTT, allowing an initial window of four small
packets, so let's assume a flow with a 200 ms RTT.  The current
lowest rate of 80 kbps (= 10 kBps) allows an initial rate of 2000
bytes/RTT, or 10 200-byte packets per RTT.  RFC 3390 already allows
four small packets per RTT, so the current low rate of 80 kbps is
roughly twice as large, for a flow with a 200 ms RTT.  My hit would
be that allowing a lower rate request of 40 kbps isn't really needed,
even for flows that send small packets every 20 ms.

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

Ah, good idea.  I will add that in.

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

Sure, I can do that.  It certainly doesn't belong where it is,
after the IANA considerations but before the conclusions.

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

Will do.  

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

Will do.

Many thanks for the feedback.

- Sally
http://www.icir.org/floyd/

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 29 May 2006 11:09:56 +0200

> even for flows that send small packets every 20 ms.

I would make a comment about that assumption. There are in the world of 
real-time media, some codecs that produce very short frames, like 5 ms. 
Also for sample based codecs there is the possibility to produce 
arbitrarily short packets. So although 20 ms is commonly the shortest 
produced by audio codecs, there are exceptions.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]