Subject: [Tsvwg] Comments on draft-scharf-tsvwg- quick-start-flow-control

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 26 Mar 2007 09:58:57 +0100

I have a few comments on the above draft:

Section 4.1, para 2
"As a consequence, a host supporting Quick-Start SHOULD enable receive
window-scaling..."
* Does adding this SYN option raise any interop issues that need to be
addressed?
* There are cases where window-scaling is not needed, even with quick-start.
A round-trip delay of 100ms, suggests 64KB limits at 4.8 Mbps. QS seems
useful in such cases, but window-scaling doesn't seem required. On the other
hand there are cases were where receiver window scaling are going to be
needed.

Section 4.4
- reordering of SYN and SYN-ACK seem a hard problem to resolve with some
"short" back-off time. The receiver has no knowledge of RTT at this time.
Backing off for a few hundred milliseconds sounds like it will prevent
reordering, but is silly on low-delay links.
* One other possibility is to repeat the "extra" ACK?

Section 5 final sentence.
- True of course, but I'd prefer to have a solution where I can that may
allow us to escape from a "controlled environment" as we learn more -
therefore this does not seem a good thing to re-state.
* Is this really an issue? - The receiver can allocate buffers in this way,
but just as in router allocations, these allocations could (perhaps?) be
avoided when resources are scarce (and QS declined, or WS declined).

Best wishes,

Gorry

---

NiTs

Section 4.1, para 1
4.1 65 kB --- or 64 KB (depending on how one defines "k"?)

---

From: Michael Scharf <[email-masked]>
Date: Fri, 30 Mar 2007 11:05:22 +0200

Hi Gorry,

thanks for reading the draft. Some comments below.

> hand there are cases were where receiver window scaling are going to be

Yes, of couse window scaling is not needed in many scenarios. However,
for a host there are IMHO no significant disadvantages of using a
scale factor of 2 or larger, which allows a fast data transmission
over paths with somewhat higher bandwidth-delay product. The statement
"enable receive window scaling" only emphasizes that window scaling
according RFC 1323 is benefitial in many scenarios where there
are also significant incentives to use RFC 4782. RFC 1323 is proposed
standard anyway. The recommendation of using RFC 1323 is thus nothing
new. The only new idea in this section is that a host could - at least
to some extend - estimate a "reasonable" scaling factor from the
approved Quick-Start rate.

I am not aware of interop issues caused by the additional ACK that the
draft proposes for some scenarios. However, other potential solutions
for the interaction of flow control and Quick-Start do cause interop
issues. I will describe some of these alternatives in another email.

> * One other possibility is to repeat the "extra" ACK?

Yes, true. Probably there is no one-fits-all approach to cope with
reordering. I think that backing off the additional ACK for a duration
of 10-100ms could be reasonable in some cases. However, such a small
delay could cause significant overhead in the host operating
system. Sending multiple ACKs could help in some corner cases. I will
mention this possibility in a future version of the draft.

> avoided when resources are scarce (and QS declined, or WS declined).

You are right. I think that this statement concerning the "controlled
environment" can be removed. Operating systems typically have a quite
sophisticated memory management and will reduce the amount of
buffer allocated to a connection when memory gets scarce.

Michael