home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
ietf
/
tcplw
/
tcplw-minutes-93jul.txt
< prev
next >
Wrap
Text File
|
1993-09-14
|
7KB
|
189 lines
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 dab@cray.com
Jim Bound bound@zk3.dec.com
Robert Braden braden@isi.edu
Walid Dabbous Walid.Dabbous@sophia.inria.fr
Jeffrey Dunn dunn@neptune.nrl.navy.mil
Francis Dupont francis.dupont@inria.fr
Robert Enger enger@reston.ans.net
Joseph Godsil jgodsil@ncsa.uiuc.edu
Frank Hoffmann hoffmann@dhdibm1.bitnet
Phil Irey pirey@relay.nswc.navy.mil
Ronald Jacoby rj@sgi.com
3
Paolo Malara malara@crs4.it
Kent Malave kent@bach.austin.ibm.com
Allison Mankin mankin@cmf.nrl.navy.mil
Willi Porten porten@gmd.de
Henry Sanders henrysa@microsoft.com
Tim Seaver tas@concert.net
Keith Sklower sklower@cs.berkeley.edu
Robert Ullmann ariel@world.std.com
Willem van der Scheun scheun@sara.nl
Paul Zawada Zawada@ncsa.uiuc.edu
4