CURRENT_MEETING_REPORT_

Reported by David Borman/Cray Research

Minutes of the TCP Large Windows Working Group (TCPLW)

The TCP Large Windows Working Group met on Wednesday, July 14 at the
27th IETF meeting in Amsterdam.  The agenda was:


  o Review of draft-ietf-tcplw-extensions-00.txt
  o Consideration of advancing RFC 1323 to Draft Standard
  o Status of SACK option


The document draft-ietf-tcplw-extensions-00.txt is a compilation of bugs
and clarification that need to be made to RFC 1323.  It was compiled by
Bob Braden.  Bob and David Borman led a walk through of the document to
help explain it and to find out if any other changes that are needed to
RFC 1323 were missed.


RTTM: Relationship to Karn's Algorithm

One of the items that Karn's algorithm addresses is how to get valid RTT
values in the presence of lost data.  With current methods, the answer
is that whenever data has to be retransmitted, no valid RTT estimate can
be made in that window.  The reason for this is that when the ACK is
received, it cannot be determined whether that ACK came from the
original packet or the retransmitted packet.

With the use of the timestamps option, this ambiguity is removed, since
the timestamp echoed in the ACK will always be from the data packet that
caused the ACK of new data to be generated.

The other part of Karn's Algorithm, that of doing exponential back-off
on retransmissions, still needs to be done.


RTTM: Which TS to Echo

The discussion that took place during the session was a bit muddled.
This summary provides a clearer explanation.

This is the one real bug in RFC 1323.  As stated currently, the TSval is
only copied to TS.Recent when a packet is received that advances the
left edge of the window.  The change allows the TSval to be copied when
the left edge of the window is advanced, or if the packet is before the
left edge of the window and it has a newer timestamp.

The scenario that this addresses is when a packet is sent, its ACK is

                                  1





lost, and so the packet is then resent.  The second packet will not
advance the left edge of the window, but will cause a duplicate ACK to
be generated.  To the sender, this will be the first ACK that is
received, so it will want to use the timestamp in that packet to update
the RTT estimate.  If the TSval is not copied from the resent packet,
the the sender will get an inflated RTT estimate.

By making this change, with the use of timestamps for doing RTT
measurements, it can be guaranteed that in the worst case, at least one
RTT measurement can be made per window.  Without the timestamps option,
in many TCP implementations one RTT estimate per window is the best
case.

Additionally, this change fixes a problem with a long-lived
unidirectional connection.  Since all the ACKs will have the same
sequence number, they would never cause TS.Recent to be updated.  With
this change, the string of ACK-only packets will cause TS.Recent to be
kept up-to-date, and allow PAWS to work properly.


TCP Options and MSS

The discussion of how the TCP MSS option interacts with the presence of
TCP and/or IP options needed some clarification.  Since many TCP
implementations us the MSS option to indicate how large of a packet can
be received without fragmentation, and the MSS does not include the
TCP/IP headers, the question is:  should it also be adjusted for the
length of the options that will probably be in each packet?

The answer is no, and when sending data the sender should always assume
that the MSS received did not account for the TCP and IP options, so the
MSS should be reduced by the length of the TCP and IP options when
determining how much data can be sent.  The following grid shows why:



                      |MSS is adjusted    |MSS is not adjusted
       _______________|to_include_options_|to_include_options_
        Sender adjusts |Packets are too    |Packets are the
        length for     |short              |correct length
       _options________|__________________|___________________
        Sender doesn't |Packets are the    |Packets are too
        adjust length  |correct length     |long
        for options    |                  |



The goal is to not send IP datagrams that have to be fragmented by IP.
Packets sent with the constraints in the lower right of this grid will
cause IP fragmentation.  The only way to ensure that this doesn't happen
is for the data sender to decrease the MSS by the length of the IP and

                                  2





TCP options.


Modification to TCP Event Processing Rules

The draft document contains a new set of rules for how to process the
TCP extensions.  Bob wanted feedback on whether or not the format was
easy to read and understand.  The general feeling was that it was easy
to read and understand.


SACK

There was some discussion of the status of the SACK option.  Right now,
there is not a lot of visible activity in this area.  There are some
test implementations of the SACK option as originally defined in
RFC 1072.  The plan is once there is some hard data on how well it
works, then a new draft document will be generated on the SACK option.


Action Items

  o Bob Braden will update RFC 1323 with the changes that are described
    in draft-ietf-tcplw-extensions-00.txt.  The new document will be
    sent to the mailing list for final review, and then sent to the
    IESG for consideration for advancement to Draft Standard status.

  o Bob Braden will update draft-ietf-tcplw-extensions-00.txt to
    include an updated description of which TS to echo to explain the
    bug as described above, and then it will be published as an
    Informational RFC.

  o David Borman will send out the current list of implementations, so
    that people can send in updates.  The updated list will be given to
    the IESG at the same time as the updated version of RFC 1323.


Attendees

David Borman             [email protected]
Jim Bound                [email protected]
Robert Braden            [email protected]
Walid Dabbous            [email protected]
Jeffrey Dunn             [email protected]
Francis Dupont           [email protected]
Robert Enger             [email protected]
Joseph Godsil            [email protected]
Frank Hoffmann           [email protected]
Phil Irey                [email protected]
Ronald Jacoby            [email protected]

                                  3





Paolo Malara             [email protected]
Kent Malave              [email protected]
Allison Mankin           [email protected]
Willi Porten             [email protected]
Henry Sanders            [email protected]
Tim Seaver               [email protected]
Keith Sklower            [email protected]
Robert Ullmann           [email protected]
Willem van der Scheun    [email protected]
Paul Zawada              [email protected]



                                  4

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.