home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_n_r / draft-partridge-e2e-ackspacing-00.txt < prev    next >
Text File  |  1997-07-30  |  9KB  |  222 lines
  1.  
  2. End-To-End Research Group                                   C. Partridge
  3. Request for Comments: DRAFT                             BBN Technologies
  4. Category: Informational                                        July 1997
  5.  
  6.  
  7.  
  8.  ACK Spacing for High Delay-Bandwidth Paths with Insufficient Buffering
  9.  
  10.                      <draft-partridge-e2e-ackspacing-00.txt>
  11.  
  12.  
  13.  
  14.                           Status of this Memo
  15.  
  16.    This document is an Internet-Draft.  Internet-Drafts are working
  17.    documents of the Internet Engineering Task Force (IETF), its areas,
  18.    and its working groups.  Note that other groups may also distribute
  19.    working documents as Internet-Drafts.
  20.  
  21.    Internet-Drafts are draft documents valid for a maximum of six months
  22.    and may be updated, replaced, or obsoleted by other documents at any
  23.    time.  It is inappropriate to use Internet- Drafts as reference
  24.    material or to cite them other than as ``work in progress.''
  25.  
  26.    To learn the current status of any Internet-Draft, please check the
  27.    ``1id-abstracts.txt'' listing contained in the Internet- Drafts
  28.    Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  29.    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  30.    ftp.isi.edu (US West Coast).
  31.  
  32.    This document is a product of the End-To-End Research Group of the
  33.    Internet Research Task Force.  Comments are solicited and should be
  34.    addressed to the author or the End-To-End Interest list (end2end-
  35.    interest@isi.edu).
  36.  
  37.    This draft expires 29 January 1998.
  38.  
  39. 1. Introduction
  40.  
  41.    Suppose you want TCP implementations to be able to fill a 155 Mb/s
  42.    path.  Further suppose that the path includes a satellite in a
  43.    geosynchronous orbit, so the round trip delay through the path is at
  44.    least 500 ms, and the delay-bandwidth product is 9.7 megabytes or
  45.    more.
  46.  
  47.    If we further assume the TCP implementations support TCP Large
  48.    Windows and PAWS (many do), so they can manage 9.7 MB TCP window,
  49.    then we can be sure the TCP will eventually start sending at full
  50.  
  51.  
  52.  
  53. <draft-e2e-ackspacing-00.txt>                           [Page 1]
  54.  
  55. RFC DRAFT                                                      July 1997
  56.  
  57.  
  58.    path rate (unless the satellite channel is very lossy).  But it may
  59.    take a long time to get the TCP up to full speed.
  60.  
  61.    One (of several) possible causes of the delay is a shortage of
  62.    buffering in routers.  To understand this particular problem,
  63.    consider the following idealized behavior of TCP during slow start.
  64.    During slow start, for every segment ACKed, the sender transmits two
  65.    new segments.  In effect, this behavior means the sender is
  66.    transmitting at *twice* the data rate of the segments being ACKed.
  67.    And keep in mind the separation between ACKs represents (in an ideal
  68.    world) the rate segments can flow through the bottleneck router in
  69.    the path.  So the sender is bursting data at twice the bottleneck
  70.    rate, and a queue must be forming during the burst.  In the simplest
  71.    case, the queue is entirely at the bottleneck router, and at the end
  72.    of the burst, the queue is storing half the data in the burst.  (Why
  73.    half?  During the burst, we transmitted at twice the bottleneck rate.
  74.    Suppose it takes one time unit to send a segment on the bottlenecked
  75.    link.  During the burst the bottleneck will receive two segments in
  76.    every time unit, but only be able to transmit one segment.  The
  77.    result is a net of one new segment queued every time unit, for the
  78.    life of the burst.)
  79.  
  80.    TCP will end the slow start phase in response to the first lost
  81.    datagram.  Assuming good quality transmission links, the first lost
  82.    datagram will be lost because the bottleneck queue overflowed.  We'd
  83.    like that loss to occur in the round-trip after the slow start
  84.    congestion window has reached the delay-bandwidth product.  Now
  85.    consider the buffering required in the bottleneck link during the
  86.    next to last round trip.  The sender will send an entire delay-
  87.    bandwidth worth of data in one-half a round-trip time (because it
  88.    sends at twice the channel rate).   So for half the round-trip time,
  89.    the bottleneck router is in the mode of forwarding one segment while
  90.    receiving two. (For the second half of the round-trip, the router is
  91.    draining its queue).  That means, to avoid losing any segments, the
  92.    router must have buffering equal to half the delay-bandwidth product,
  93.    or nearly 5 MB.
  94.  
  95.    Most routers do not have anywhere near 5 MB of buffering for a single
  96.    link.  Or, to express this problem another way, because routers do
  97.    not have this much buffering, the slow start stage will end
  98.    prematurely, when router buffering is exhausted.  The consequence of
  99.    ending slow start prematurely is severe.  At the end of slow start,
  100.    TCP goes into congestion avoidance, in which the window size is
  101.    increased much more slowly.  So even though the channel is free,
  102.    because we did not have enough router buffering, we will transmit
  103.    slowly for a period of time (until the more conservative congestion
  104.    avoidance algorithm sends enough data to fill the channel).
  105.  
  106.  
  107.  
  108.  
  109. <draft-e2e-ackspacing-00.txt>                           [Page 2]
  110.  
  111. RFC DRAFT                                                      July 1997
  112.  
  113.  
  114. 2. What to Do?
  115.  
  116.    So how to get around the shortage of router buffering?
  117.  
  118. 2.1 Cascading TCPs
  119.  
  120.    One approach is to use cascading TCPs, in which we build a custom TCP
  121.    for the satellite (or bottleneck) link and insert it between the
  122.    sender's and receiver's TCPs, as shown below:
  123.  
  124.  
  125.      sender ---- Ground station -- satellite -- ground station -- receiver
  126.  
  127.        |---------------|   |------------------------|  |---------------|
  128.        | loop 1        |   |       loop 2           |  | loop 3        |
  129.        |---------------|   |------------------------|  |---------------|
  130.  
  131.  
  132.    This approach can work but is awkward.  Among its limitations are:
  133.    the buffering problem remains (at points of bandwidth mismatches,
  134.    queues will form); the scheme violates end-to-end semantics of TCP
  135.    (the sender will get ACKs for data that has not and may never reach
  136.    the receiver); and it doesn't work with encryption (i.e. if data
  137.    above the IP layer is encrypted).
  138.  
  139. 2.2 ACK Spacing
  140.  
  141.    Another approach is to find some way to spread the bursts, either by
  142.    having the sender spread out the segments, or having the network
  143.    arrange for the ACKs to arrive at the sender with a two segment
  144.    spacing (or larger).
  145.  
  146.    Changing the sender is feasible, although it requires very good
  147.    operating system timers.  But it has the disadvantage that only
  148.    upgraded senders get the performance improvement.
  149.  
  150.    Finding a way for the network to space the ACKs would allow TCP
  151.    senders to transmit at the right rate, without modification.
  152.    Furthermore, it can be done by a router.  The router simply has to
  153.    snoop the returning TCP ACKs and spread them out.  (Note that if the
  154.    transmissions are encrypted, in many scenarios the router can still
  155.    figure out which segments are likely TCP ACKs and spread them out).
  156.  
  157.    There are some difficult issues with this approach.  The most notable
  158.    ones are:
  159.  
  160.       1. What algorithm to use to determine the proper ACK spacing.
  161.  
  162.  
  163.  
  164.  
  165. <draft-e2e-ackspacing-00.txt>                           [Page 3]
  166.  
  167. RFC DRAFT                                                      July 1997
  168.  
  169.  
  170.       2. Related to (1), it may be necessary to known when a TCP is in
  171.       slow-start vs. congestion-avoidance, as the desired spacing
  172.       between ACKs is likely to be different in the two phases.
  173.  
  174.       3. What to do about assymetric routes (if anything).  If the ACKs
  175.       do not return through the ACK-spacing router, it may not be
  176.       possible to do ACK spacing.
  177.  
  178.  
  179.    Despite these challenges the approach has appeal.  Changing software
  180.    in a few routers (particularly those at likely bottleneck links) on
  181.    high delay-bandwidth paths could give a performance boost to lots of
  182.    TCP connections.
  183.  
  184. Credit and Disclaimer
  185.  
  186.    This memo presents thoughts from a discussion held at the recent
  187.    meeting of the End-To-End (E2E) Research Group.  The particular idea
  188.    of ACK spacing was developed by during the meeting by Mark Handley
  189.    and Van Jacobson in response to an issue raised by the author, and
  190.    was inspired, in part by ideas to enhance wireless routers to improve
  191.    TCP performance [1].
  192.  
  193.    The material presented is a half-baked suggestion and should not be
  194.    interpreted as an official recommendation of the Research Group.
  195.  
  196. References
  197.  
  198.    1. H. Balakrishnan, V.N. Padmanabhan, S. Seshan and R.H. Katz, "A
  199.    Comparison of Mechanisms for Improving TCP Performance over Wireless
  200.    Links", Proc. ACM SIGCOMM '96, pp. 256-269.
  201.  
  202.  
  203.  
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221. <draft-e2e-ackspacing-00.txt>                           [Page 4]
  222.