Subject: [Tsvwg] Re: draft-ietf-tsvwg-quickstart-00: Some questions about the current rev.

From: Sally Floyd <[email-masked]>
Date: Sat, 20 Aug 2005 17:02:07 -0700

Gorry -

Many thanks for the feedback.

>Page 20: Section 4.4 para 2 from end of page 20.
>"this addresses the problem  of a overly-large congestion window from an
>overly-large measurement of the round trip time."
>- I don't understand the statement, it may be true, but I am not sure what
>it means.

I will revise it to clarify, saying the following:

"This is necessary because the TCP sender's round-trip-time estimate
when the Quick-Start Response is received might be longer than
succeeding round-trip times, e.g., because of delays at routers
processing the IP QuickStart option, or because of delays at the
receiver in responding to the Quick-Start Request packet.  In this
case, an overly-large round-trip-time estimate would cause the TCP
sender to translate the approved Quick-Start sending rate into an
overly-large initial congestion window, with the TCP sender receiving
an ACK for the first Quick-Start packet before the entire congestion
window has been used.  Thus, when the TCP sender receives the first
ACK for a Quick-Start packet, the sender reduces its congestion
window to the amount that has actually been used."

>-----------------
>Page 22, section 4.6.2 - Path MTU Discovery
>- The document says that setting the DF bit on a large number of overly
>large packets is "not desirable".
>- I really think the document should provide some guidance on the use of
>PMTU, at least to say that the implementor must use an IETF-approved method
>to determine the appropriate packet size.  The default behaviour being the
>use of the smallest guaranteed MTU.

I am happy to say that the implementor must use an IETF-approved
method to determine the appropriate packet size, but that doesn't
solve the problem of what packet sizes to use with the multiple
packets sent in the initial window of data, because at that time
PMTUD or other current IETF-approved methods for determining the
Path MTU have not yet completed.

>- The current text asks more questions than it seems to answer.

Yep, instead of saying "One possibility would be for the sender to
send one large packet in the initial window with the DF bit set,
and to send the remaining packets in the initial window with a
smaller MTU of 576 bytes", we will revise it to say that the sender
SHOULD do that, if the sender uses Quick-Start to send a large
initial window.

>-----------------
>Page 22: section 4.6.3 final para on page 22.
>- The final paragraph recommends a change to the initial RTO setting for
>TCP. I found this VERY disappointing, the sort of networks that I had wanted
>to use this with have a round trip path delay that can vary and may be
>greater than 1 second, which if I understand means that QS will make the
>performance worse. I also have concerns that changing the TCP initial RTO
>value to 1 can have some very bad effects on the remainder of the session,
>in some styles of implementation (e.g. where the SYN timer is used to
>initialise the RTO for the transfer phase).
>- The statement here also seems at first thought to be in contradiction to
>recommending use in GPRS networks (section 8.3).
>- Is it absolutely necessary to do it this way?

Yeah, we are planning to change this.

>-----------------
>Page 26: section 6.2, point "multiple paths"
>- I can't decide if this is true or not, I suspect that the QS method can
>inject much more data than would typically be found using Slow-Start (even
>with many sessions). What do others think?

I think it is true that a path change after a Quick-Start request has
been approved has essentially the same effect as a path change
after a TCP connection has reached that congestion window through
slow-start.  But it is true that a short connection might reach a
higher congestion window using Quick-Start, than it would have without
Quick-Start.  I will revise it to say that.

I also plan to add the following text about multiple-path routing to
Section 3.3:

"A router that uses multipath routing for packets within a single
connection MUST NOT approve a Quick-Start request.  Quick-Start
would not perform robustly in an environment with multipath routing,
where different packets in a connection routinely follow different
paths.  In such an environment, the Quick-Start request and some
fraction of the packets in the connection might take an underutilized
path, while the rest of the packets take an alternate, congested
path."

"As discussed in Section 6.2, Quick-Start could also give poor
performance when there is a routing change immediately after the
Quick-Start request is approved, and the Quick-Start data packets
follow a different path from that of the original Quick-Start
Request.  However, as noted in Section 6.2, this is similar
to what can happen without Quick-Start when a connection path is
changed after the connection had already established a certain
sending rate on the original path."

>-----------------
>Page 29: Section 6.4
>"routers should be discouraged"
>- This seems rather weird to me, or unclear. I believe that dropping excess
>low-priority traffic is exactly what you would wish a DS or CBQ router to
>do? If the DS SLA, for instance, said it was lower priority...then  it
>dropping may be an appropriate treatment. What does this section really
>mean?

I will delete that sentence.  As the previous sentence says, "We
don't address this context further in this paper, since it is
orthogonal to the specification of Quick-Start."  I will just leave
it at that.

>-----------------
>Page 35: 
>"GRPS round-trip times are typically up to one second"
>- This is possibly so, but it is not necessarily always so, as the paragraph
>later suggests, the total end-to-end delay includes queuing delay and the
>non-GPRS segment of the Path. Delay can therefore increase above 1 sec.
>Since total delay is what matters, the assertion of this paragraph is
>perhaps confusing!

I will try to clarify it.

...
>Finally, I find the organisation of the text still rather mixed-up.  I think
>the document could be improved by a small amount of reorganisation to make
>this a useful Experimental RFC. Some parts read as more informative, others
>as normative. Maybe it is critical to say this about a -00 WG draft, I'm
>sorry. 
>
>* There does not yet seem to be a consistent use of standards language in
>those sections which are normative, describing the actual protocol spec.
>
>* It is not immediately clear which sections MUST be read to implement
>correctly, which must be read to deploy it or develop router support and
>which are informative about the method/design - I would much rather have
>seen a section (or sections) with a spec, and some later sections which give
>informative guidance. 

I will look at this, and see if a little reorganization will help.

Many thanks for the feedback.

I will be answering your other two email messages in the next day or two.

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

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 22 Aug 2005 17:58:49 +0100

My thoughts in-line.

Sally Floyd wrote:

> receiver in responding to the Quick-Start Request packet. 
To me, this seems clearer if written:
"This is necessary because when the Quick-Start Response is received,
the TCP sender's round-trip-time estimate may be longer than
for succeeding round-trip times," ...

> In this
> overly-large initial congestion window, 
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

- I think I understand this as a congestion window that is paced over
too long a period?

> with the TCP sender receiving

> Path MTU have not yet completed.

PMTUD cache *MAY* already have a value. If it doesn't have a cached value, I 
thought the recommendation was probe, but use the smallest PMTU that is 
guarenteed (as seems to be said below)?

> SHOULD do that, if the sender uses Quick-Start to send a large
OK.

<snip>
> Quick-Start.  I will revise it to say that.
Seems more fair.

> sending rate on the original path."
This is much clearer.

<snip>

> http://www.icir.org/floyd/

Best wishes,

Gorry