Subject: mailing list
From: [email-masked] (Jim Fiori - Special Projects)
To: [email-masked]
Date: Mon, 18 May 92 11:36:58 EDT

Can I be placed in this mailing list please?

Thanks

Date: Fri, 15 May 92 12:30:08 EDT
From: [email-masked] (Jim Fiori - Special Projects)
To: [email-masked]
Subject: RFC 1323

Has anyone implemented this RFC (TCP Extensions for High Performance) on
SunOS 4.1.X? I've started to do so and I'd like to know about problems/results,
etc.

Any information would be greatly appreciated.

Jim Fiori
(410) 312-1726

Date: Thu, 14 May 92 20:44:11 -0500
From: Thomas Skibo <[email-masked]>
To: [email-masked]
Subject: Second revision of BSD implementation of RFC 1323 extensions now available.
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]

Folks:

Now available is the second revision of my 4.3 BSD implementation
of the RFC 1323 TCP Extensions.  This revision has the following
features in addition to the first revision:

	* No more setsockopt()'s!  Window scaling is automatic and based
	  on receive buffer space at connect time.
	
	* Correct (more correct?) time-stamps and PAWS.  The first revision
	  handled PAWS wrong.

	* General spiffying up.

Also available is a draft tech report about experiences with the extensions.
It's an informal paper about the implementation and some experiments done with
the extensions.  I appreciate any comments on it.

The patch is for BSD net release 2 TCP code.  A README file briefly describes
using the extensions (much easier now that scaling is automatic).  The README
file, the patch, and the tech report in PostScript are all in a (compressed)
shell archive file available anonymous ftp from uxc.cso.uiuc.edu
(128.174.5.50).  Go to directory /pub, go to binary mode, and get
the file "tcplw.shar.Z".  Running the shell archive will dump three
files into the current working directory: README, tcpx.patch, and tcpx.ps.

Hope it's useful.

-skibo

------
Thomas Skibo		University of Illinois, Dept. of CS.
[email-masked]	ph: 217-333-7937

Date: Thu, 14 May 92 16:52:37 PDT
From: [email-masked]
Posted-Date: 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]

	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: Wed, 13 May 92 15:40:55 EDT
From: [email-masked] (Fred Bohle)
To: [email-masked], [email-masked]
Subject: Re:  TCP Large Window Implem. at Sandia
Cc: [email-masked]

I have implemented the same options in our product, SNS/TCPacces.
If you would like to test your implementation with mine, please emain
me directly.

Fred
------------------------------------------------------------------------
Fred Bohle			EMAIL: [email-masked]
Interlink Computer Sciences	AT&T : 301-317-6600 
9145 Guilford Road, Suite 175
Columbia, MD 21046
------------------------------------------------------------------------

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

Date: Wed, 13 May 92 13:25:19 -0500
From: Thomas Skibo <[email-masked]>
To: [email-masked]
Subject: Re:  TCP Large Window Implem. at Sandia
Cc: [email-masked]

> There are a couple of differences between my implementation and the code 
> that I've looked at for Cray and Univ of Illinois (after I'd already done
> the SunOS code), and I'd appreciate your comments.

> 1.  I calculated the shift count proposed by each end from the TCP receive
>     buffer size.  It seems to me that this is the best way for each node to
>     ensure that the window will fit into 16 bits.  I noticed that the other 
>     two implementations I studied added a new TCP option for the user to 
>     call to establish a shift count, and I can't see the reason for this 
>     other than to let the user play around with the parameter for research
>     purposes.  Otherwise, I'd rather keep the changes to the application 
>     code to a minimum.

Yes.  This is MUCH better.  My latest revision no longer uses setsockopt()'s
to control window scaling.  The setsockopt() was gross and the latest RFC
states something to the effect that the application interface shouldn't
change.

> 2.  The above design decision revealed what I consider to be a design flaw
>     in TCP (probably generic Berkeley code and not just SunOS).  The client
>     side worked fine, but the server couldn't get the expanded receive buffer
>     side before the connection was accepted; hence, it couldn't calculate the
>     correct shift count.  If I did the 'setsockopt' for the RCVBUF after the
>     'accept', the connection was established before the large buffer size
>     was set.  If I did the 'setsockopt' on the 'master' socket before the
>     accept, it didn't propogate to the new socket created by the 'accept'.
>     I solved the problem by adding code to 'tcp_attach' to get the buffer 
>     sizes from the 'parent' socket using the 'so_head' pointer (if it was 
>     valid) and calling 'sbreserve' with those buffer sizes.  It would have 
>     been possible to copy buffer sizes in the socket routines, but I was 
>     trying to limit mods to the TCP routines.  Anybody else run into this 
>     problem?:

The socket buffer sizes DO propagate to the new socket.  It's done
in sonewconn() in uipc_socket2.c.

What I'm doing now is calculating the scaling value from the buffer
sizes when a PRU_CONNECT or PRU_LISTEN is done on a TCP socket.  So,
in the case of a listen socket, you do the setsockopt( SO_RCVBUF ) call
before you make the listen() call.  When a listening TCP accepts a
connection, the created connection gets the same socket buffer space
as the listen socket.  My implementation has the created TCP connection
"inherit" the scaling value from the listen TCP.

A better way might be to have the window scaling computed from
the socket buffer space at the time that a listening TCP accepts a
connection.  One problem with my method is that if you changed the buffer
space of a socket already listening, the scaling value of subsequent
connections would be incorrect.  I'd change it but the current implementation
is thoroughly tested and I'm desperately trying to finish finals and document
all this stuff before I run off and join the ranks of the gainfully employed.

My latest revision of the extensions has the above change as well as
significant changes to time-stamps (I was doing a few things wrong).
I'll be making them available by the end of the week.  I've also got a
tech report in the works and it should be available by Monday.

------
Thomas Skibo		University of Illinois, Dept. of CS.
[email-masked]	ph: 217-333-7937

Date: Wed, 13 May 92 11:28:25 MDT
From: [email-masked] (Nov-C. Douglas Brown)
To: [email-masked]
Subject: TCP Large Window Implem. at Sandia
Cc: [email-masked]

I've just joined the 'tcplw' mailing list and wanted to discuss my
implementation of TCP large windows at Sandia National Labs with the rest 
of the group.  I've modified TCP on SunOS 4.1.1 to do the window scaling 
and have tested it successfully against our Cray.  Have designed the mods
to do the RTT according to RFC1072, but will redesign to implement the 
latest recommendations in the current draft that I got yesterday.  We don't
necessarily need SACK, as our studies show it to be useful only in a narrow
range of error rate, and our long-haul links have been good enough that 
retransmissions due to errors shouldn't be a problem.

There are a couple of differences between my implementation and the code 
that I've looked at for Cray and Univ of Illinois (after I'd already done
the SunOS code), and I'd appreciate your comments.

1.  I calculated the shift count proposed by each end from the TCP receive
    buffer size.  It seems to me that this is the best way for each node to
    ensure that the window will fit into 16 bits.  I noticed that the other 
    two implementations I studied added a new TCP option for the user to 
    call to establish a shift count, and I can't see the reason for this 
    other than to let the user play around with the parameter for research
    purposes.  Otherwise, I'd rather keep the changes to the application 
    code to a minimum.

2.  The above design decision revealed what I consider to be a design flaw
    in TCP (probably generic Berkeley code and not just SunOS).  The client
    side worked fine, but the server couldn't get the expanded receive buffer
    side before the connection was accepted; hence, it couldn't calculate the
    correct shift count.  If I did the 'setsockopt' for the RCVBUF after the
    'accept', the connection was established before the large buffer size
    was set.  If I did the 'setsockopt' on the 'master' socket before the
    accept, it didn't propogate to the new socket created by the 'accept'.
    I solved the problem by adding code to 'tcp_attach' to get the buffer 
    sizes from the 'parent' socket using the 'so_head' pointer (if it was 
    valid) and calling 'sbreserve' with those buffer sizes.  It would have 
    been possible to copy buffer sizes in the socket routines, but I was 
    trying to limit mods to the TCP routines.  Anybody else run into this 
    problem?: