home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / 97apr / tcpimpl-minutes-97apr.txt < prev    next >
Text File  |  1997-05-29  |  6KB  |  139 lines
  1. Editor's Note:  These minutes have not been edited.
  2.  
  3.  
  4. The first formal meeting of the TCP Implementor's Working Group was held at
  5. 1:30 PM on Monday, April 7th.  The chairs of the group are Steve Alexander
  6. (sca@sgi.com) of Silicon Graphics and Vern Paxson (vern@ee.lbl.gov) of
  7. Lawrence Berkeley Labs.
  8.  
  9. Vern started off the meeting by presenting the agenda.  In order to ensure that
  10. the attendees were up-to-date, Vern then presented a brief overview of the
  11. scope, charter, and deliverables of the group.
  12.  
  13. A brief overview of the policy on naming of vendor names followed.  The policy
  14. is currently that it is acceptable to mention vendor names explicitly on the
  15. mailing list, or in informal discussions, but not in official products of the
  16. group, e.g. RFCs.  In addition, naming names is inappropriate at formal WG
  17. meetings.  In general, this is motivated by the belief that information
  18. about bugs in vendor releases tends to become out-of-date rather quickly, and
  19. that embedding such information in documents with a long life-time is
  20. problematic.  One exception to this rule is that it is generally felt that
  21. referring to "BSD" or "BSD-derived" in a generic sense would be acceptable.
  22.  
  23. Vern then presented an overview of the current format of the I-D on known
  24. TCP problems.  This document is an enumeration of problem descriptions, with
  25. each description containing:
  26.     - Name
  27.     - Classification
  28.     - Description
  29.     - Significance (this is an impact, not a MUST/SHOULD/MAY)
  30.     - Implications
  31.     - Traces (if available)
  32.     - Information about Detection
  33.     - Suggested Fix
  34.     - Any Specific Information pertaining to the problem
  35.  
  36. Vern gave an overview of the current I-D status.  At present, it has
  37. information about four problems:
  38.     - no initial slow start
  39.     - no slow start after retransmit due to timeout
  40.     - retransmission of different data
  41.     - failure to retain above-sequence data (violates SHOULD, not MUST)
  42.  
  43. The problems remaining to be documented include:
  44.     - initial RTO too low
  45.     - uninitialized congestion window
  46.     - slow-start with two segments
  47.     - violations of delayed ACK rules
  48.     - failure to correctly set PSH
  49.     - Brakmo/Peterson header prediction bug
  50.     - Brakmo/Peterson deflation bug
  51.     - fast retransmit with timestamp sends two segments
  52.     - Dawson keepalive problem
  53.     - failure to correctly implement Nagle's algorithm
  54.     - keepalive behavior (0-byte/1-byte)
  55.     - failure to ACK above-sequence data
  56.     - predictable ISN security problem
  57.     - SYN-flood security problem
  58.     - failure to implement fast retransmit/recovery
  59.     - RTO estimation on slow links
  60.     - replies to random ACKs
  61.     - ICMP error handling
  62.     - half-duplex close ignores subsequent data
  63.     - urgent pointer confusion
  64.  
  65. At this point, Vern briefly enumerated issues surrounding test tools.  The
  66. chairs are soliciting a list for compilation into an I-D.  The current goal
  67. is to have a first draft of this I-D available by the Munich meeting in August.
  68. There are a few technical issues related to some of the existing tools, such
  69. as Steve Parker's Packet Shell.  These are:
  70.     - a portable "raw socket" interface for such tools to use
  71.     - how to suppress responses from the host TCP
  72.  
  73. These need to be discussed, either directly between the interested parties, or
  74. on the group mailing list.
  75.  
  76. Vern closed with a request for volunteers to help with the following areas:
  77.     - reporting any problems not on the current list
  78.     - working on detailed descriptions of known problems for inclusion in
  79.       the I-D
  80.     - developing new testing tools
  81.  
  82. This concluded the formal agenda and open discussion began.  The following
  83. issues were raised:
  84.     
  85.     Is the group formally attempting to survey all available
  86.     implementations for the known problems, or in an effort to find
  87.     new issues?  Answer: not really.
  88.  
  89.     Bob Braden asked what percentage of the attendees are or have been
  90.     implementors.  Roughly 30 indicated they are implementors, and
  91.     another 10-15 that they were former implementors.  Total attendance
  92.     was recorded as ~70.
  93.  
  94.     It was suggested that perhaps bake-offs should be started up again.
  95.     This was generally considered to be a good idea; it is not clear that
  96.     this is the responsibility of the group, and this should be discussed
  97.     on the list and with the IESG.
  98.  
  99.     Matt Mathis raised the issue of backward compatibility and suggested
  100.     that workarounds for defective implementations should be well-known,
  101.     easy to test for, and easy to disable in the event that they cause
  102.     performance overhead when not actually needed.  He felt that the
  103.     group should recommend that the workarounds be obsoleted.
  104.  
  105.     Jim Gettys brought up an issue with connections remaining in
  106.     FIN-WAIT-2 indefinitely.  This appears to be most common when
  107.     using the Apache web server, but may have other causes as well.
  108.     This should be added to the list of known issues.
  109.  
  110.     Perry Metzger brought up the issue of minimizing memory usage in
  111.     stacks which fail to retain state after the application has closed.
  112.     This probably requires further discussion on the mailing list.
  113.  
  114.     Bob Briscoe suggested the the specification is ambiguous about slow-
  115.     start after an idle period.  This needs to be reviewed.
  116.  
  117.     Matt Mathis suggested that part of the above problem is due to failure
  118.     to agree on what how long of a time value is used to determine whether
  119.     or not the connection is "idle."  He felt that substituting the term
  120.     "long idle" for "idle" would help stress the point that implementations
  121.     which don't slow-start even after an hour or so of being idle are out
  122.     of spec.  The precise definition of "long idle" vs. "short idle" is
  123.     still an area for research, but an hour is clearly too long.
  124.  
  125.     Perry Metzger brought up the fact that RFC 1948 (Defending Against
  126.     Sequence Number Attacks) is not currently a standards-track document.
  127.     Vern suggested that perhaps the group should recommend it in one of
  128.     the new documents.  We should probably also investigate whether the
  129.     status of the document could (or should) be changed, possibly to
  130.     BCP.
  131.  
  132.     Ian Heavens raised the issue of problem taxonomy.  This may just be an
  133.     issue of how the current I-D is organized.  We should discuss this
  134.     on the list.
  135.  
  136. The meeting concluded at this point.
  137.  
  138. Steve Alexander
  139.