1 / 8

Quick-Start for TCP and IP

Quick-Start for TCP and IP. draft-ietf-tsvwg-quickstart-00.txt Jain, S. Floyd, M. Allman, and P. Sarolahti TSVWG, August 2005 This and earlier presentations:: www.icir.org/floyd/talks. QuickStart with TCP, for setting the initial window :. In an IP option in the SYN packet,

knox
Télécharger la présentation

Quick-Start for TCP and IP

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Quick-Start for TCP and IP draft-ietf-tsvwg-quickstart-00.txt Jain, S. Floyd, M. Allman, and P. Sarolahti TSVWG, August 2005 This and earlier presentations:: www.icir.org/floyd/talks

  2. QuickStart with TCP, for setting the initial window: • In an IP option in the SYN packet, the sender's desired sending rate: • Routers on the path decrement a TTL counter, • and decrease the allowed sending rate, if necessary. • The receiver sends feedback to the sender in the SYN/ACK packet: • The sender knows if all routers on the path participated. • The sender has an RTT measurement. • The sender can set the initial congestion window. • The TCP sender continues using normal congestion control.. • From an initial proposal by Amit Jain

  3. Last IETF: • We reported on new material about possible attacks on Quick-Start. • We were going to do a final revision, and then were to be ready for Working Group Last Call, to go as Experimental. • Since then, we have made a (hopefully final) round of revisions.

  4. Changes from draft-amit-quick-start-04.txt: • If the Quick-Start Response is lost in the network, it is not retransmitted. • Added a suggestion to send one large packet in the initial window for PMTUD, and to send the other packets at 576 bytes. • Added sections on "Misbehaving Middleboxes", and on "Attacks on Quick-Start” (material reported at the last IETF). • Specified that a Quick-Start-capable router denying a request SHOULD delete the Quick-Start option, and if this is not possible, SHOULD zero the QS TTL and the Rate Request fields.

  5. More changes: • Specified that retransmitted SYN packets should use an RTO of three seconds, and a new Initial Sequence Number (for measuring the RTT).

  6. Two questions sent to the mailing list: • One technical issue: • About retransmitted SYN packets. • One substantive possible change: • Section 3.6: A Quick-Start Nonce?

  7. Retransmitted SYN Packets: • Are there any TCP implementations that would react badly to a retransmitted SYN packet using a different Initial Sequence Number?

  8. Section 3.6: A Quick-Start Nonce? • There are four unused bits in the IP option - • Use them for a Quick-Start Nonce? • Some times the receiver knows the original rate request R. • Goal of QS Nonce: discourage receivers from lying about the value of the received rate request. • Mechanics: • Sender sets QS Nonce to a random value. • When a router reduces the approved rate request, it sets the QS Nonce to a new random value. • Receiver reports back value to sender. • If no routers reduced the rate request, then the QS Nonce should have its original value. • Should we add this to the spec?

More Related