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

From: Sally Floyd <[email-masked]>
Date: Mon, 12 Sep 2005 10:55:35 -0700

Gorry -

My apologies in being so late for the feedback for this one.

...
>>>Page 20: Section 4.4 para 2 from end of page 20.
...
>> "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. 
>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," ...

Thanks, done.

>> 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, 
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>- I think I understand this as a congestion window that is paced over
>too long a period?

More or less.

I changed it from this:

    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. 

to this:

    In this case, an
    overly-large round-trip-time estimate would cause the TCP sender to
    translate the approved Quick-Start sending rate in bytes per second
    into a congestion window that is larger than needed, 
    with the TCP sender receiving an ACK for
    the first Quick-Start packet before the entire congestion window has
    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.
>> 
>
>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)?

Yep.  I added this:

  If the sender knows the Path MTU when the initial window is sent
  (e.g., from a PMTUD cache or from some other IETF-approved method),
  then the sender should use that MTU for segments in the initial window.

Many thanks for the feedback (and my apologies again for the very late reply).

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

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