home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / 97apr / tcpsat-minutes-97apr.txt < prev    next >
Text File  |  1997-05-29  |  8KB  |  226 lines
  1. Editor's Note:  These minutes have not been edited.
  2.  
  3.  
  4. Mail*Link« SMTP               TCPSAT BOF Minutes
  5.  
  6. TCP Over Satellite BOF
  7. ======================================================================
  8. April 10 and 11, 1997
  9.  
  10. Chair: Aaron Falk, TRW (Aaron.Falk@trw.com)
  11.  
  12. Minutes reported by Mark Allman (mallman@cs.ohiou.edu).
  13.  
  14.  
  15. April 10, 1997
  16. ======================================================================
  17.  
  18. Aaron Falk started the meeting with a brief overview of the agenda
  19. and meeting purpose.  The BOF was called to determine if interest
  20. existed for the formation of a working group that would be charged
  21. with documenting the issues involved in using TCP on satellite
  22. channels.  
  23.  
  24. Tim Shepard, BBN (shep@bbn.com) presented a view of the problem that
  25. satellite channels present:
  26.  
  27.     -the big problem is the delay
  28.     -generally receive windows are low in the net; an 8K receive
  29.      window can provide maximum throughput of 128 kilobits/second 
  30.     -this throughput is not bad in some situations (compared to a
  31.      modem, for example)
  32.     -but, to use all available bandwidth, we need bigger windows
  33.     -but, when using big windows, slow start can cause a large
  34.      amount of packet loss
  35.     -selective acknowledgments (SACKs) help this problem
  36.     -the problem is well understood on the receiver side
  37.     -we need to allow bigger windows with window scaling and
  38.          PAWS (RFC 1323) 
  39.     -we need to generate selective acknowledgments (RFC 2018) 
  40.     -the problem is not well understood on the sender side; more
  41.      research is needed
  42.     -a question was raised about whether RED queuing would help;
  43.      answer: it might, but we don't know yet
  44.  
  45. Yongguang Zhang, Hughes (ygz@isl.hrl.hac.com) presented some recent
  46. research results using the NASA ACTS system:
  47.  
  48.     -experimental environment:
  49.     -ACTS satellite
  50.     -Reno/SACK FreeBSD machines
  51.     -workload: tcplib traffic
  52.     -24 KB windows
  53.     -avg. file size: 27 KB
  54.     -compared to a terrestrial network with 50 ms RTT
  55.     -measured useful traffic/hour
  56.     -terrestrial channel was able to better utilize the available
  57.      network capacity when compared to the satellite channel 
  58.     -ongoing experiments:
  59.     -ATM vs. non-ATM on either side of the satellite channel
  60.     -other TCP versions (Tahoe, Reno, Vegas, 4K slow start
  61.          proposal) 
  62.     -testing under delay emulation
  63.     
  64. Shawn Ostermann, Ohio Univ. (ostermann@cs.ohiou.edu) presented some
  65. of the current solutions being proposed and studied:
  66.  
  67.     -short transfers do not work very well (small number of segments
  68.      vs. the long RTT and slow start are against us)
  69.     -long transfers have problems too (the windows are big, which
  70.      make the congestion control algorithms take a long time to ramp
  71.      up (either at the beginning of the transfer, or after a loss)
  72.     -OU built a multiple connection FTP client and server (XFTP)
  73.     -was able to utilize 96% of available bandwidth
  74.     -lessons from XFTP:
  75.     -we need bigger windows
  76.     -need more buffering in the routers
  77.         (and maybe alternate queuing, like RED)
  78.     -detecting and correcting loss
  79.         -cant let pipe empty because:
  80.         -takes 4 seconds to slow start to 100 KB
  81.         -takes 50 seconds to recover from one packet loss
  82.          (using congestion avoidance)
  83.         -we need to use fast retransmit and recovery
  84.         -we need to use SACKs
  85.         -we need to use MTU discovery so that we are sending as
  86.          much data as possible in each segment
  87.     -what we understand:
  88.         -long connections with no loss do very well
  89.         -short and medium connections do not do well
  90.         -short transfers never leave slow start
  91.         -delayed ACKs make slow start even worse
  92.     -what might help? (open issues)
  93.         -bigger initial windows (Floyd)
  94.         -more aggressive window increase algorithm (Allman,
  95.          et. al) 
  96.         -the slow start changes above have increased throughput
  97.          and did not significantly decrease goodput or increase
  98.          loss in tests at OU
  99.         -do not perform congestion control if a drop is due to
  100.          corruption, rather than congestion
  101.         -use an ssthresh estimator
  102.         -use RED
  103.     -goal:
  104.         -extend TCP while keeping backward compatibility
  105.         -do not introduce mechanisms that will hurt other types
  106.          of networks
  107.     -a question was asked about using indirect-TCP (i.e., breaking
  108.      the TCP connection into 2 connection at the basestation);
  109.      Shawn answered that it was an interesting idea that he did not
  110.      know a lot about
  111.  
  112. Discussion:
  113.  
  114.     Aaron started a discussion about whether or not a WG should be
  115.     created to document the problems of using TCP over satellite
  116.     links and some possible solutions.
  117.  
  118.     -the proposed charter calls for cataloging problems and
  119.          mitigating mechanisms
  120.     -out-of-scope:
  121.         -non-interoperable TCP implementations
  122.         -substantial changes to the TCP protocol
  123.         -link-layer changes
  124.         -research
  125.  
  126.     Some comments:
  127.  
  128.     -What is the purpose of a working group?  Use a mailing
  129.          list, since the scope is small, the group will be
  130.          short-lived and the deliverable is only one I-D/RFC
  131.     -Allyn Romanow (co-area director for transport area)
  132.          commented that there is already quite a bit of initiative
  133.          involved in this group and that a staged approach is
  134.          worthwhile to try out
  135.     -Matt Mathis: unfocused WGs are unhealthy and this will be a
  136.          very focused WG, so it is a good experiment
  137.     -Fred Baker: this type of WG will make the net more useful
  138.          in the third world and therefore, we should make the
  139.          effort.  Also, these are not just satellite questions but
  140.          apply to high delay*bandwidth links everywhere.
  141.     -Allyn conducted a straw poll which was in favor of creating
  142.          the WG
  143.  
  144.     Goal: to deliver a document at the IETF meeting in Washington,
  145.     DC (12/97).
  146.     
  147.     WWW Site:    
  148.     http://www.isr.umd.edu/CCDS/IPoS/
  149.  
  150.     TCP Over Satellite mailing list:
  151.     To access it send email to:
  152.         majordomo@listserv.trw.com
  153.     with the following in the body of the message:
  154.         subscribe tcp-over-satellite
  155.  
  156.     Interim meeting might be necessary.
  157.     
  158.     
  159. April 11, 1997
  160. ======================================================================
  161.  
  162. Eric Travis outlined the contents of the draft that will be
  163. produced. 
  164.  
  165. Purpose:
  166.     -identify and explain performance problems, including pointers
  167.      to simulation results, emulation results and experiments
  168.      conducted over real satellites
  169.     -identify and explain mechanisms that help overcome the outlined
  170.      performance problems
  171.     -categorize engineering problems and research problems
  172.     -discussion:
  173.     -we need a document for people running real networks that
  174.          outlines the problems and solutions for problems
  175.          encountered in the satellite environment
  176.     -want to outline various network topologies that contain
  177.      satellites: 
  178.     -examples given:
  179.  
  180.         node-sat-node
  181.         node-sat-net-node
  182.         node-net-sat-net-node
  183.         node-???-sat-???-node
  184.  
  185.     -specific issues:
  186.     -identify and describe:
  187.         -large delay*bandwidth
  188.         -long feedback path
  189.         -asymmetric channels
  190.         -corruption
  191.         -???
  192.     -provide a problem statement and explanation of possible
  193.          solutions for each of the above
  194.         -discussion (what do they provide to each environment
  195.          outlined above)
  196.         -references to research results
  197.         -tag each area as an engineering or research problem
  198.         -validation of problem/solution
  199.     -outline interactions between mitigating techniques
  200.     -outline research areas
  201.     -provide recommendations
  202.     -what is available?
  203.     -what is useful?
  204.     -what should be applied?
  205.  
  206. Discussion:
  207.     -outline the constraints, i.e. that the solutions should not have
  208.      negative impacts on the Internet
  209.     -we need to provide validation where possible
  210.     -maybe include something about application or network layer
  211.      protocols, if they have an impact on TCP
  212.  
  213. Work Schedule:
  214.     -1st draft target date: 6/30/97
  215.     -2nd draft target date: last day to submit drafts before Munich
  216.      meeting 
  217.     -3rd draft target date: post Munich
  218.     -4th draft target date: October
  219.  
  220. Aaron asked people doing TCP over satellite research to drop a short
  221. note to the mailing list outlining their work.
  222.  
  223.  
  224.  
  225.  
  226.