Subject: FYI: Last Call
From: dab@hemlock (David Borman)
To: [email-masked]
Date: Tue, 25 Feb 92 09:28:55 CST

This is for the revised document, draft-ietf-tcplw-tcpext-02.txt
			-David Borman, [email-masked]

To: IETF <[email-masked]>
Cc: [email-masked]
From: IESG Secretary <[email-masked]>
Subject: Last Call: TCP Extensions for High Performance
Date: Mon, 24 Feb 92 13:11:19 -0500

The IESG has received a request from the TCP Large Windows Working Group
to recommend the Internet Draft "TCP Extensions for High Performance"
be published as a Proposed Standard.

The IESG plans to issue a recommendation in the next few weeks, and
solicits final comments on this elevation.  Please send any comments
to the [email-masked], or [email-masked] mailing lists by March
5th.

Greg Vaudreuil
IESG Secretary

Date: Fri, 14 Feb 92 09:55:45 PST
From: [email-masked]
Posted-Date: Fri, 14 Feb 92 09:55:45 PST
To: [email-masked]
Subject: Progress...
Cc: [email-masked]

Friends,

Yesterday I finally finished editing a new version of the I-D
containing window scaling, RTTM, and PAWS, without SACK, and submitted
it to be published as a new Internet Draft.  It was proof-read by Dave
Borman and by Liming Wei here at ISI; my thanks to both eagle-eyes!
Thanks also to all who contributed comments at the IETF meeting.

My understanding is that Dave Borman will now put on his IESG hat and
introduce this version into the Internet standards track.

Bob Braden

Date: Wed, 5 Feb 92 04:58:07 GMT
From: [email-masked] (Rob Warnock)
To: [email-masked]
Subject: Re: What to do???
Cc: [email-masked], [email-masked]

In the TCPLW mailing list, [email-masked] (Jim DeMarco) writes:
+---------------
| >       1) Leave the SACK option as currently stated in the draft,
| >          and publish it.
| >       2) Change the SACK from a hard ack to a soft ack, and
| >          publish it.
| I'd like to vote for #2.  This proposed option has the least amount of
| *real-world* experience (as far as I know).  Let's implement soft
| SACKs and find out how well it works.
+---------------

Note for comparison that XTP has "soft" SACKs, and XTP is installed in
a number of environments (albeit almost all *low*-delay LANs). Also, XTP
uses 32-bit sequence numbers in SACKs (that is, 8 bytes per range SACK'd).

Small XTP tutorial (skip if not interested), omitting details not relevant
to selective ACKs:

- XTP retransmission is "sender driven". The receiver *never* volunteers
  information unless the sender asks (with the SREQ or DREQ bit in the flags)
  for the receiver to send back a control packet.

- Each packet, control or data, carries SEQ and DSEQ sequence numbers in both
  directions.

- In a data packet, SEQ is the same as TCP SEQ. In a control packet from the
  sender, SEQ is what would be sent with the next "new" data, that is, it's
  one greater than the highest sequence number ever consumed by output data
  for that connection (a "high water mark").

- DSEQ is similar to TCP ACK, except that DSEQ guarantees that the data has
  been delivered all the way to the XTP client, and is not still sitting in
  the transport layer buffers. Retransmission buffers may not be freed
  until the data in them has been covered by DSEQ. DSEQ is a "hard ACK"
  [compare with RSEQ, below].

- Control packets (e.g., ones that come back from a receiver because the 
  sender sent SREQ/DREQ) don't carry data, but do carry a bunch of additional
  "header" fields. The SACK-related ones are:

  ALLOC - Like TCP's WINDOW, but 32 bits (so no "large window option" needed).

  RSEQ - Similar to TCP ACK, in that it contains one plus the highest sequence
	 of contiguously received data without error so far. However, RSEQ is
	 a "soft ACK"; it's advisory only. Until DSEQ covers the data, it still
	 may need retransmission. That is, the receiver is allowed to "renege"
	 an RSEQ value in a later control packet [provided DSEQ <= new RSEQ].

  NSPANS - The number of "spans" (SACKs, or sequence-number pairs). Spans, if
	 present (NSPANS may be 0), follow the end of the fixed portion of a
	 control packet.

  A span - Each "span" is a pair (low,high) of sequence numbers indicating a
	   contiguous range of sequence numbers of data received without error. 
	   Since sequence numbers are 32 bits, each span is 8 bytes. The spans
	   must be sorted in increasing sequence, and may not overlap RSEQ or
	   each other. Spans are purely advisory (soft SACK).

So each span describes both a contiguous sequence of data received (SACK). They
also describe a non-empty set of "gaps" between the lower sequence number of
the span and the higher sequence number of the next-lower span (or RSEQ, for
the lowest span). There may or may not be a gap between the highest sequence
number of the highest span and the sender's SEQ. The gaps are thus the logical
candidates for retransmission.

XTP specifically allows a sender to ignore some or all of the spans it gets
back from a receiver if necessary (e.g., because of implementation limits on
a small system), and (for example) base retransmission on just SEQ and RSEQ.

So XTP, at least, has not only soft SACKs (spans), but separate soft ACK (RSEQ)
and hard ACK (DSEQ) as well.

Caveat: While the DSEQ/RSEQ/spans/SEQ scheme has been used "successfully" in
XTP, it has been almost entirely in high-speed low-latency LAN environments,
where data loss rates are very low (and what there is if it is often due to
network adapter misdesign!). As far as I know, there has been no extensive
trial of XTP in a "long, fat pipe" environment. [Greg?]

-Rob

-----
Rob Warnock, MS-9U/510		[email-masked]
Silicon Graphics, Inc.		(415)335-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94039-7311