Re: [Tsvwg] Quick-Start for TCP and IP

[Mohammed Ashraf <[e-mail]>]

I have some basic queries  on  Quick-Start for TCP and IP draft.  I
appreciate if  you could clarify this.

Here are my queries:
 1. Draft says that Quick start request option will be included as a part
of IP header, while  quick start response as part of
      TCP header. Is it because the  quick start response need not be
processed by IP?

2. I guess IP header option should keep 32 bit boundry (i.e multiple of 4
bytes ). But in the case of quick start request, it  has got 5 bytes. Is
the padding to be done here assumed?

Thanks in advance,
Ashraf


Sally Floyd wrote:

> Amit Jain and I have a new internet-draft on
> Quick-Start for TCP and IP, available at:
>
> http://www.icir.org/floyd/papers/draft-amit-quick-start-00b.txt
>
> We would appreciate any feedback from this communitu.
>
> This is something that it would take some time to deploy, and it
> might or might not be a good idea, but it could significantly reduce
> transfer times for moderate-sized best-effort traffic over
> underutilized, high-bandwidth infrastructures...
>
> We would note that this is not (at the moment) an official tsvwg
> work item, or even an official internet-draft (since we missed the
> submission deadline).
>
> Thanks,
> - Sally
>
> Abstract:
>
>    This draft outlines an optional Quick-Start mechanism for transport
>    protocols to determine an optional allowed initial congestion window
>    or initial sending rate at the start of a data transfer.  This
>    mechanism is designed to be used by a range of transport protocols;
>    however, in this document we only describe its use with TCP and IPv4.
>    By using Quick-Start, a TCP host, say, host A, would indicate its
>    desired initial sending rate in packets per second in a Quick Start
>    Request option in the IP header of the initial TCP SYN or SYN/ACK
>    packet. Each router in turn could either approve the specified
>    initial rate, reduce the specified initial rate, or indicate that
>    nothing above the default initial rate for that protocol would be
>    allowed.  The Quick-Start mechanism also can determine if there are
>    routers along the path that do not understand the Quick Start Request
>    option, or have not agreed to the initial rate described in the
>    option. If all of the routers along the path have agreed to the
>    initial rate in the Quick-Start Request, then TCP host B communicates
>    this to TCP host A in a transport-level Quick-Start Response in the
>    answering SYN/ACK or ACK packet.  Quick-Start is designed to allow
>    TCP connections to use high initial windows in circumstances when
>    there is significant unused bandwidth along the path, and all of the
>    routers along the path support the Quick-Start Request.  We note that
>    this is currently not a mature proposal, but an outline of one
>    possible path of development in the IP protocol, and a request for
>    feedback from the community.
>
> ----
> -- Forwarded Message
>
> Date:    Mon, 24 Jun 2002 09:31:48 -0700
> From:    Sally Floyd <[e-mail]>
> To:      [e-mail]
> cc:      Amit Jain <[e-mail]>
> Subject: Internet drafts submission of draft-amit-quick-start-00a.txt
>
> I would like to submit this internet-draft.
>
> http://www.icir.org/floyd/papers/draft-amit-quick-start-00a.txt
> draft-amit-quick-sta.. 23-Jun-2002 22:13    36k
>
> I unfornately just realized this morning that the deadline was
> 9AM ET instead of 5PM ET, as I had been assuming, so probably
> you are not able to accept this submission.  But I thought I
> would try nevertheless: the file on the web server is dated
> last night, and therefore the draft itself was completed by
> the deadline...
>
> - Sally
>
> ------- End of Forwarded Message
>
> _______________________________________________
> tsvwg mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/tsvwg





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