1 / 9

Quick-Start for TCP and IP: Improving Data Transfer Efficiency

This document introduces the Quick-Start mechanism for TCP and IP, which allows senders to quickly adjust their sending rate based on network conditions. It discusses the operation of Quick-Start, its benefits, and potential deployment scenarios.

jarrettk
Download Presentation

Quick-Start for TCP and IP: Improving Data Transfer Efficiency

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-amit-quick-start-03.txt Jain, S. Floyd, M. Allman, and P. Sarolahti TSVWG, October 2004

  2. QuickStart with TCP, in the SYN exchange: • 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. The Quick-Start Request Option for IPv4 0 1 2 3 +----------+----------+----------+----------+ | Option | Length=4 | QS TTL | Rate | | | | | Request | +----------+----------+----------+----------+ • Explicit feedback from all of the routers along the path would be required. • This option will only be approved by routers that are significantly underutilized. • No per-flow state is kept at the router.

  4. Quick-Start in the NS Simulator • Added to NS by Srikanth Sundarrajan.

  5. Changes fromdraft-amit-quick-start-02.txt: • Using Quick-Start in the Middle of a Connection. • The request would be on the total rate, not on the additional rate. • The request is now in bytes per second, not packets per second. • New sections include: • When to use Quick-Start • TCP: Responding to a Loss of a Quick-Start Packet • TCP: A Quick-Start Request after an Idle Period • Quick-Start with DCCP • Quick-Start in IP Tunnels • …

  6. Possible Deployment Scenarios: • Intranets? • Centralized control over end nodes and routers. • Could include high-bandwidth, high-delay paths to remote sites. • Paths over satellite links? • High bandwidth, high delay.

  7. Design Issues: IP Options, ICMP, or RSVP? • IP Options: • Blocked by some middleboxes • Takes the slow path in routers? • ICMP: • Blocked by some middleboxes. • Mechanisms would be needed to address all routers along the path, and get one answer. • RSVP: • Soft state in routers is not needed.

  8. Design issues: the encoding of the Rate Request • Linear function: • Minimum request of 80 Kbps, maximum request of 20.5 Mbps. • 80-Kbps increments • Powers of two: • Use 4 bits of the 8-bit field. • Minimum request of 80 Kbps, maximum request of 1.3 Gbps. • Doubling the request from one to the next.

  9. Questions: • Would the benefits of Quick-Start be worth the added complexity? • Quick-Start Request packets would not take the fast path in routers. • Is there a compelling need to add some form of congestion-related feedback from routers such as this (in addition to ECN)? • Is there a compelling need for more fine-grained or more frequent feedback than Quick-Start? • Are there other mechanisms that would be preferable to Quick-Start?

More Related