Re: [Tsvwg] AD review of draft-ietf-tsvwg-quickstart-05

[Sally Floyd <[e-mail]>]

> 	  I would like to know whether async speeds for the flows
> 	  are an issue. What I mean by async flows is say a 1Gb capacity
> 	  flow in one direction and say under 10Mb in the reverse direction.
> 	  Any two figures that are drasticly different would be acceptable.

Section 2 says the following:

    "The data transfer in the two directions of a connection traverses
     different queues, and possibly even different routers.  Thus, any
     mechanism for determining the allowed sending rate would have to be
     used independently for each direction."

> 	  Thus, request sending rate SHOULDN'T also need to "reserve"
> 	  return bandwidth. And ack reduction in the reverse direction
> 	  would also indicate a form of congestion.

As Section 2 states, any  mechanism for determining the allowed
sending rate would have to be used independently for each direction.

The question about the possibility of congestion for the ack packets
on the reverse path is a good point.   I will add some discussion about 
it.

The current mechanism for using Quick-Start for TCP only uses a
Quick-Start request for data - there is no proposal for a corresponding
Quick-Start request for the bandwidth that would be used by the
pure ack packets in the reverse direction.  This seems ok to me.

However, it is true that if the TCP sender is using the maximal
request of 1Gbps, and 1500-byte data packets, this means a bandwidth
of 13 Mbps for the pure ack packets in the reverse direction if
the TCP receiver is acking every other packet.

In the long run, I would hope that TCP uses congestion control on
pure ack packets, in a similar way to that of CCID2 in DCCP.  (It
is on my to-do list to write this up in an internet-draft one day...)
If this was done, then there would be a TCP option for the TCP
sender to use to tell the TCP receiver to only ack one in every K
data packets, for the value of K specified in the option.  If we
specified in the Quick-Start draft that all Quick-Start-capable end
nodes should understand this TCP option, then the option could be
used by the TCP sender, when sending Quick-Start data packets, to
tell the TCP receiver to only ack every K packets.

An alternate possibility, without a TCP option for ack rates, would
be for a Quick-Start-capable TCP receiver to impose its own limits
on its sending rate for pure ack packets after it receives a
Quick-Start request.  The TCP receiver could have an estimate of
the RTT (e.g., measured from the time between sending the Quick-Start
feedback to receiving the "Report of Approved Rate", or from an
encoding of the sender's estimated RTT added to the "Report of
Approved Rate"), and the TCP receiver could use the info in the
received "Report of Approved Rate" to limit its sending rate for
pure ack packets.

Feedback?

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