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

From: Sally Floyd <[email-masked]>
Date: Tue, 08 Aug 2006 20:34:18 -0700

Lars -

> find my review of draft-ietf-tsvwg-quickstart-05 below. I didn't find 
> any major technical issues, it's mostly small nits.
>
> One overall meta-comment, however, is that the document mixes 
> specification (description of the mechanism and protocols) and 
> applicability statements (discussion of behavior, effects, issues, 
> plus long appendices discussing related work, design options not 
> taken, a rebuttal to a review, etc.) This makes it difficult for the 
> reader to extract the mandatory-to-implement pieces out of the overall 
> work.
>
> For a Standards Track document, I'd require that this be addressed, 
> probably by refactoring the document into multiple smaller and more 
> focused ones. Since this is going for Experimental, I'm not going to 
> require this, but still would like to strongly suggest that the 
> authors discuss whether presenting the large body of work in a small 
> number of more focused documents (maybe: architecture, IP-layer 
> extension specification, TCP extension specification, applicability 
> statement) may not be more readable.

Many thanks for the review.  We made all the changes, and submitted the
revised version, at:
http://www.icir.org/floyd/papers/draft-ietf-tsvwg-quickstart-06.txt
http://www.icir.org/floyd/papers/draft-ietf-tsvwg-quickstart-06.ps

We deleted one appendix (the one on "Feedback from Bob Briscoe"),
and added two paragraphs to the Introduction saying that all of the
formal specifications are in Sections 3, 4, and 6.

- Sally

      Changes from draft-ietf-tsvwg-quickstart-05:

      * Minor editing in response to IESG feedback.
        This includes changing one "should" to "SHOULD",
        and changing formating of the IANA Considerations
        section.

      * Clarifying in the Introduction that the QS router
        does not give preferential treatment to QS packets.
        In response to email from Fil Dickinson.

      * Added a discussion of interactions between
        Quick-Start and draft-ietf-pmtud-method.  Feedback
        from IESG.

      * Deleted Appendix F on "Feedback from Bob Briscoe".
        From feedback from the IESG about deleting unnecessary
        appendices.

      * Added a paragraph to the Introduction about which
        sections contain normative references, and which
        sections are general discussion.  Feedback from
        IESG.

---

From: Erblichs <[email-masked]>
Date: Wed, 16 Aug 2006 10:51:24 -0700

Sally Floyd,

	Requesting sending rate:

	  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.

	  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.

	  I did not see these two above items mentioned in this draft.

	Mitchell Erblich
	-----------------

---

From: Sally Floyd <[email-masked]>
Date: Wed, 16 Aug 2006 14:48:18 -0700

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

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

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 21 Aug 2006 10:42:12 +0100

Sally,

>formal specifications are in Sections 3, 4, and 6.

I'll take a look to check it's all still OK with this appendix removed.

Cheers

Bob

____________________________________________________________________________
Bob Briscoe, <[email-masked]>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196

---

From: Sally Floyd <[email-masked]>
Date: Mon, 21 Aug 2006 11:59:05 -0700

> I'll take a look to check it's all still OK with this appendix removed.

Many thanks.  If there is something there that really needs to stay in 
the final
RFC, that is fine by me.

- Sally