Subject: Mail archives
From: [email-masked] (David A. Borman)
To: [email-masked], [email-masked]
Date: Wed, 31 Mar 93 17:56:54 CST

Ok, mail archives for "[email-masked]" and "[email-masked]"
mailing lists are now available (finally...).

The big problem in the past is that where I save the archive is
behind our firewall, with no ftp access.  This is still the case.

However...  you can now access the mailing list archives by
using telnet to an alternate port number:

	Telnet to port 23000 on berserkly.cray.com (128.162.96.70)

You will be talking to an interactive program that will ask you
to select the archive of your choice.

Once an archive is selected, the interface is similar to running
the BSD Mail program, but it is read only.  It also has some
different options, many things from BSD Mail are missing, so
things aren't exactly the same, but they are close enough for now.

The program doesn't enable any telnet options, so if you have
a telnet that supports kludge linemode, you'll go into kludge
linemode, a handy feature so that you can do line editing...

This is a program that I hacked together in the last couple
of days.  I make no guarantees that it will always work, and
I haven't had time to really fully test it out.  If you run
into problems (like the connection gets dropped or the session
hangs), please drop me a note, being as specific as you can as
to what you were doing at the time, and if it is reproducable.

Attached is a sample run of just connecting to the server.

		-David Borman, [email-masked]

------
% telnet berserkly.cray.com 23000
Trying 128.162.96.70...
Connected to berserkly.cray.com.
Escape character is '^]'.

Cray Research Mail Archive Server
        Please report any problems to [email-masked]

This is an simple mail archive server, that provides a user
interface similiar to the BSD mail program.  Type '?' for help.

List of available mail archives:
        1) tcplw        ([email-masked])
        2) telnet-ietf  ([email-masked])

Please select an archive number ('q' to quit): 1
Parsing archive...
Mail archive for tcplw
135 messages, 321639 bytes

> 133 [email-masked]       Mar 25 11:40 1993   33/1229  "Re: TCP MSS & Timestam"
  134 [email-masked]       Mar 26 14:34 1993   41/1460  "RFC-1323 to Draft"
  135 [email-masked]       Mar 26 15:37 1993  126/3680  "Re: TCP MSS & Timestam"
tcplw> ?
info               print archive information
type   [msg list]  type selected messages
all                type the entire archive
+                  type the next message
-                  type the previous message
=                  print current message number
h                  print a screen of headers
from   [msg list]  print selected headers
z                  print next screen of headers
z-                 print last screen of headers
arch               select a new archive
idle   [idle time] get (set) idle time
screen <# lines>   set # of lines in screen
quit               quit
?                  print this list

tcplw> quit
Goodbye.
Connection closed by foreign host.
%

Date: Fri, 26 Mar 1993 13:37:34 -0800
From: [email-masked] (Bob Braden)
To: [email-masked]
Subject: Re: TCP MSS & Timestamps
Cc: [email-masked]

Dave,

Here is a summary of the way I handle TCP options in my version of
the RFC-1323 extensions, for SunOS4.1.  Perhaps something like this
should be included in RFC-1323-bis?  Do you believe it?

Bob

______________________________________________________________

   /* Handling TCP options and Maximum Segment Size (MSS) */

Connection State block (TCB) includes the following quantities:

 *  maxseg:  Largest data block to send in a packet.

 *  maxopd:  Largest (data + TCP options) area in a packet

 *  Received_MSS: 
             The MSS value received from the remote host in an MSS
             option.  This variable is initialized to 536 (or a 
             cached value).

_________________________________________________________________

When receive a segment [tcp_input]:

   (1) When receive SYN in LISTEN or SYN-SENT state:

       o  Parse the options

       o  If receive an MSS option, store its value into Received_MSS
                (and perhaps cache it).

       o  Call tcp_nice_mss().

_________________________________________________________________

When send a segment [tcp_output]:

   (1) Get packet buffer and copy header template into it.

   (2) Build options in buffer.

       o MSS option is sent with value tcp_mss(). 
                   (But it is not sent if value is 536).

   (3) Given option length optlen, compute actual data to send:

	len = min( data_to_send, maxseg, maxopd - optlen );

   (4) Copy len bytes of data into buffer.

_________________________________________________________________

/* The following algorithms are in fractured-C */

/*  tcp_nice_mss():
 *
 * Compute: maxseg = maximum data to ever send in one segment, and 
 *          maxopd = maximum total space for data and TCP options.
 *
 * Maxseg is rounded down to a "nice" value (a multiple of 512) if possible
 * without wasting more than 1/16 of the space.  Maxopd is set to handle
 * the "normal" options; if the actual options exceed this size, they will
 * eat into maxseg.  Conversely, if actual data len < maxseg, then more
 * room is available for options.
 *
 * Also initialize the congestion/slow start window to be a single
 * segment if the destination isn't local.
 */  
tcp_nice_mss()
    {
	/*
	 *  Compute maxopd = <maximum segment size we can send> - 40
	 */
	if (!islocal)
		maxopd = min( Interface_MTU - 40, Received_MSS, pathMTU - 40);
			/* Until MTU Discovery is available, use heuristic:
				pathMTU = 576. */
	else
		maxopd = min( Interface_MTU - 40, Received_MSS);
            
	maxseg = maxopd;
	if (<Allowed to send TSopt>)
		maxseg -= sizeof(TSopt);

	maxseg = NICE_SIZE(maxseg);  /* round down if possible */

		/* If not on local network, force initial slowstart */
	if (!is_local)
		congestion_window = maxseg;
}

/*
 *  tcp_mss()
 *
 *  This routine returns computes the MSS option to be sent; it depends
 *  only on the interface MTU (for a system like BSD that does not have
 *  a fixed-size packet receive buffer):
 */
tcp_mss()
  {
  return(Interface_MTU - 40)
  }

Date: Fri, 26 Mar 1993 12:34:10 -0800
From: [email-masked] (Bob Braden)
To: [email-masked], [email-masked], [email-masked]
Subject: RFC-1323 to Draft

Dave,

Before we advance 1323 to Draft Standard, I think we need to clean up
three things:

1. Note that Karn algorithm is not needed when RTTM is used.

2. Write some words about how to do TCP options vis a vis MSS.

3. Correct the algorithm error you pointed out.  I am pretty well
   convinced that the *right* answer is:

       TSrecent is updated when
                 SEG.TS >= TSrecent AND SEG.SEQ <= Last_ACK_Sent.

   I am still a bit fuzzy about whether there is a different formulation
   that also works, but this formulation seems to have the right properties
   and fits well with PAWS.  In particular, it explicitly constructs a
   monotonic sequence of values in TSrecent.

If we can get general agreement with this, I will start editing RFC-1323
to make a new document.

Bob Braden

Date: Thu, 25 Mar 1993 09:39:59 -0800
From: [email-masked] (Bob Braden)
To: [email-masked], [email-masked]
Subject: Re: TCP MSS & Timestamps

Dave,

This is a belated reply to your carefully-reasoned discussion of how
to handle TCP options vis a vis MSS.  I would note that your conclusion
is inescapable.  It would not make sense for the receiver to adjust the
MSS.  Unless the receiver has precognition, it cannot know how much
option space the sender will use.

This also agrees with 4.2.2.6 of the Host Requirements RFC 1122.

This is an area of the Internet architecture that has caused much
confusion, because we didn't get it quite right.  I'm still not sure
what "right" would be, but we didn't get there!

Bob

To: [email-masked]
Reply-To: [email-masked] (Thomas Skibo)
From: [email-masked] (Thomas Skibo)
Subject: Re: 1323 question
Date: Wed, 17 Mar 1993 03:23:26 GMT

Bob:

> Here is a single test that I think may work:
> 
> *>       (2)  If the packet fits at the left window edge or earlier,
> *>            and if it its timestamp is later than TSrecent:
> *>
> *>               SEG.SEQ <= Last.ACK.sent
> *>               and TSval > TS.Recent
> *>   
> *>            then the TSval from the segment is copied to TS.Recent;
> *>            otherwise, the TSval is ignored.
> 
> Bob

One advantage to this change is that (I think) it fixes the problem that
PAWS does not protect us from old, duplicate ACKs in uni-directional
connections.  I dug this up from way, way back:

> From: [email-masked]
> Posted-Date: Thu, 14 May 92 16:52:37 PDT
> Message-Id: <[email-masked]>
> Received: by braden.isi.edu (4.1/4.0.3-4)
> 	id <AA13866>; Thu, 14 May 92 16:52:37 PDT
> To: [email-masked]
> Subject: Re:  Does PAWS work for duplicate ACKs in uni-directional connections?
> Cc: [email-masked]
> Status: R
> 
> 
> 	From [email-masked] Wed May 13 11:51:34 1992
> 	Date: Wed, 13 May 92 13:51:28 -0500
> 	From: Thomas Skibo <[email-masked]>
> 	To: [email-masked]
> 	Subject: Does PAWS work for duplicate ACKs in uni-directional connections?
> 	Cc: [email-masked]
> 
> 	Bob:
> 
> 	The messages about 64-bit sequence numbers reminded me of a point I
> 	should have brought up a couple weeks ago when I noticed it.
> 
> 	As PAWS is defined in the RFC, a completely uni-directional connection
> 	will not have any protection against old duplicate ACKs with wrapped
> 	acknowledgement numbers.  Since a pure ACK has a zero length, the
> 	comparison
> 
> 		SEG.SEQ <= Last.ACK.sent < SEG.SEQ + SEG.LEN
> 
> 	always fails and so TS.recent is never updated at the sender (the
> 	receiver of the acknowledgement).  TS.recent stays at the initial
> 	time-stamp value received at connection set-up and so ALL acknowledgements
> 	pass the PAWS test.
> 
> 	Would this test be more appropriate?
> 
> 		SEG.SEQ <= Last.ACK.sent < SEG.SEQ + SEG.LEN	if SEG.LEN > 0
> 
> 		SEG.SEQ == Last.ACK.sent			if SEG.LEN == 0
> 
> 
> 	Am I overlooking something?
> 
> 	------
> 	Thomas Skibo		University of Illinois, Dept. of CS.
> 	[email-masked]	ph: 217-333-7937
> 
> 
> This is a very interesting point.  My first reaction is that the problem you
> point out is real, but I don't like your fix.  Strictly, TS.recent should
> be updated with the "latest" ACK.  This should correspond to the latest
> window update, as determined by the SND.WL1 and SND.WL2 variables.  So
> this makes me suspect that the TS.recent update is actually in the
> wrong place, and ought to be in the ACK field processing (p. 72 of
> RFC-793).  Interesting.
> 
> Bob Braden

Date: Tue, 16 Mar 93 19:21:44 -0800
From: [email-masked] (Thomas Skibo)
To: [email-masked] (Bob Braden)
Subject: Re: 1323 question
Cc: [email-masked]

Bob:

> Here is a single test that I think may work:
> 
> *>       (2)  If the packet fits at the left window edge or earlier,
> *>            and if it its timestamp is later than TSrecent:
> *>
> *>               SEG.SEQ <= Last.ACK.sent
> *>               and TSval > TS.Recent
> *>   
> *>            then the TSval from the segment is copied to TS.Recent;
> *>            otherwise, the TSval is ignored.
> 
> Bob

One advantage to this change is that (I think) it fixes the problem that
PAWS does not protect us from old, duplicate ACKs in uni-directional
connections.  I dug this up from way, way back:

> From: [email-masked]
> Posted-Date: Thu, 14 May 92 16:52:37 PDT
> Message-Id: <[email-masked]>
> Received: by braden.isi.edu (4.1/4.0.3-4)
> 	id <AA13866>; Thu, 14 May 92 16:52:37 PDT
> To: [email-masked]
> Subject: Re:  Does PAWS work for duplicate ACKs in uni-directional connections?
> Cc: [email-masked]
> Status: R
> 
> 
> 	From [email-masked] Wed May 13 11:51:34 1992
> 	Date: Wed, 13 May 92 13:51:28 -0500
> 	From: Thomas Skibo <[email-masked]>
> 	To: [email-masked]
> 	Subject: Does PAWS work for duplicate ACKs in uni-directional connections?
> 	Cc: [email-masked]
> 
> 	Bob:
> 
> 	The messages about 64-bit sequence numbers reminded me of a point I
> 	should have brought up a couple weeks ago when I noticed it.
> 
> 	As PAWS is defined in the RFC, a completely uni-directional connection
> 	will not have any protection against old duplicate ACKs with wrapped
> 	acknowledgement numbers.  Since a pure ACK has a zero length, the
> 	comparison
> 
> 		SEG.SEQ <= Last.ACK.sent < SEG.SEQ + SEG.LEN
> 
> 	always fails and so TS.recent is never updated at the sender (the
> 	receiver of the acknowledgement).  TS.recent stays at the initial
> 	time-stamp value received at connection set-up and so ALL acknowledgements
> 	pass the PAWS test.
> 
> 	Would this test be more appropriate?
> 
> 		SEG.SEQ <= Last.ACK.sent < SEG.SEQ + SEG.LEN	if SEG.LEN > 0
> 
> 		SEG.SEQ == Last.ACK.sent			if SEG.LEN == 0
> 
> 
> 	Am I overlooking something?
> 
> 	------
> 	Thomas Skibo		University of Illinois, Dept. of CS.
> 	[email-masked]	ph: 217-333-7937
> 
> 
> This is a very interesting point.  My first reaction is that the problem you
> point out is real, but I don't like your fix.  Strictly, TS.recent should
> be updated with the "latest" ACK.  This should correspond to the latest
> window update, as determined by the SND.WL1 and SND.WL2 variables.  So
> this makes me suspect that the TS.recent update is actually in the
> wrong place, and ought to be in the ACK field processing (p. 72 of
> RFC-793).  Interesting.
> 
> Bob Braden

Date: Tue, 16 Mar 1993 17:06:34 -0800
From: [email-masked] (Bob Braden)
To: [email-masked], [email-masked]
Subject: Re: 1323 question

Dave,

I see your point: the timestamp resolves the ambiguity that forced
the Karn algorithm (whether an ACK refers to the original packet
or to the retransmitted packet), so maybe we don't need Karn if
we have timestamps.

Here is a single test that I think may work:

*>       (2)  If the packet fits at the left window edge or earlier,
*>            and if it its timestamp is later than TSrecent:
*>
*>               SEG.SEQ <= Last.ACK.sent
*>               and TSval > TS.Recent
*>   
*>            then the TSval from the segment is copied to TS.Recent;
*>            otherwise, the TSval is ignored.

Bob

Date: Mon, 15 Mar 93 17:26:39 -0600
From: [email-masked] (David Borman)
To: [email-masked], [email-masked], [email-masked]
Subject: Re: 1323 question

Bob,

Ok, I've flipped back and forth on whether I agree or disagree
while writing this up (with a different reason for each flip-flop).
In the end, I believe that there is valid reasoning for not
ignoring the TSecr in ACKs to retransmitted packets (and hence
modifying 1323 to guarantee that the TSecr in those packets is
valid for RTT measurement).

Short and sweet, if the packet loss rate exceeds 1 packet
per RTT, and you ignore the TSecr on ACKs to retransmitted
packets, you'll probably never get a valid RTT measurement.

Here's my thinking, let me know if I've missed something.
I'm assuming the sender is using Van's fast retransmit
code, so that packet losses will be noticed within about
one RTT of when the packet was sent.  If you don't do that,
all this is still true, only worse...

For using Timestamps to measure RTT:

If you lose a data packet, all ACKS due to successive
packets after the lost packet, and before the retransmitted
packet, will NOT acknowledge new data.  They will all cause
duplicate ACKs to be generated.  The current rules will cause
the TSecr in all these ACKs to be ignored.  So, you've already
lost all the timing information between the lost packet and
when you retransmit the lost packet.  Assuming the packet after
the lost packet is the next one that the receiver expects, now
that the hole is filled, its ACK will contain a valid TSecr that
can be used correctly in updating the RTT.  In fact, all packets
between the retransmitted packet, and the next lost packet, can
generate valid RTT values.  Whether or not you use the ACK to the
retransmitted packet in RTT calculations doesn't change any of
this.  Not using the TSecr of the ACK of the retransmitted
packet means you only lose one RTT measurement, that of the
retransmitted packet.  But if that's the only valid RTT
measurement...

The old "one RTT measurement per RTT" scenario:

When you lose a packet you lose the RTT info for that packet.
You also continue to lose RTT info until that packet is ACKed.
Once you get that ack, you can start timing again.  This means
that you go for 2 RTT without getting valid RTT info.

Summaries:

One-timing-per-RTT:
	It will take at least one RTT to realize that a
	packet has been lost.  It will take another RTT
	to get the ACK for the retransmitted packet.  If
	you lose another packet in that time frame, you
	lose big.

	Loss rate > 1 per 2*RTT means no accurate RTT
	measurement.

Current Timestamps (ignore TSecr in ACKs to retransmitted packets):
	Lose if next lost packet is before or immediatly
	after the retransmitted packet is sent.  It takes
	at least one RTT to determine that a packet has
	been lost and be retransmitted.  If another packet
	is lost before the retransmitted packet is received,
	or if the packet immediatly following the retransmitted
	packet is lost, you lose bit.

	Loss rate > 1 per RTT means no accurate RTT
	measurement.

Fix Timestamps to allow timing of retransmitted packets:
	This is the same as the Current Timestamps.  However,
	the big difference is that you are guaranteed at
	least one valid RTT measurement per successfuly
	retransmitted and ACKed packet (if you can't do that,
	you won't have a connection very long...), even if
	the loss rate exceeds 1 packet per RTT.

	Loss rate > 1 per RTT means that you'll still get
	accurate RTT measurement, at about the same accuracy
	as the "One-timing-per-RTT" gets without any loss.

So, it seems to me that for high-loss networks, there is a
definite win to being able to use the TSecr in acks to
retransmitted packets.  I believe that my proposed changes
in my previous message will obtain that goal.

			-David Borman, [email-masked]

> From [email-masked] Mon Mar 15 15:24:27 1993
> Date: Mon, 15 Mar 1993 13:24:33 -0800
> From: [email-masked] (Bob Braden)
> To: [email-masked], [email-masked]
> Subject: Re: 1323 question
> 
> 
> Dave,
> 
> I believe you have noted a documentation fault, not an algorithm
> fault.  The addition of the RFC-1323 changes do not, as Van has noted
> to me in the past, mean that one should stop doing all the other good
> things -- in particular, one should continue to apply Karn's
> algorithm.  This means that it does not matter what TSecr arrives in
> the the ACK, the sending side should ignore it because it ACKs a packet
> that has been retransmitted.
> 
> Does this make sense?
> 
> Bob

Date: Mon, 15 Mar 1993 13:24:33 -0800
From: [email-masked] (Bob Braden)
To: [email-masked], [email-masked]
Subject: Re: 1323 question

Dave,

I believe you have noted a documentation fault, not an algorithm
fault.  The addition of the RFC-1323 changes do not, as Van has noted
to me in the past, mean that one should stop doing all the other good
things -- in particular, one should continue to apply Karn's
algorithm.  This means that it does not matter what TSecr arrives in
the the ACK, the sending side should ignore it because it ACKs a packet
that has been retransmitted.

Does this make sense?

Bob

Date: Mon, 15 Mar 93 14:39:58 CST
From: [email-masked] (David A. Borman)
To: [email-masked]
Subject: 1323 question

Hi.

I've been looking at calculating retransmission timers using
the Timestamps option.  Either we missed a case in 1323, or I
missed where it is documented in 1323.

The scenario is straight forward.  A host sends a packet,
the remote side acks it, the ack is lost, the orginating
host resends the packet, and the remote host acks it again.

                                              TS.Recent
            <A, TSval=1> ------------------->
                                                  1
 (lost)              <---- <ACK(A), TSecr=1>

 (ReXmit)   <A, TSval=4> ------------------->
                                                  ???
                     <---- <ACK(A), TSecr=???>

One of two things has to happen here.  Either "???" has
to be set to "4", or the originating host has to ignore
the TSecr in the packet for calculating RTT.  (I don't like
the latter, because it means that the originator has to
keep track of everything that has been retransmitted until
it it acknowledged.)