Subject: Re: Source Code
From: Christian Huitema <[email-masked]>
To: [email-masked] (Steve Wise)
Cc: [email-masked] (Thomas Skibo), [email-masked]
Date: Thu, 15 Oct 92 09:02:49 -0500

I hope the following description will give yoiu an idea of what INRIA is...

Christian Huitema
================================
The National Institute for Research in Computer Science and Automation (INRIA)
is a French Scientific and Technological Public Institute under the
responsability of the Ministry of Research and of the Ministry of Industry.
INRIA's missions are:

 * basic and applied research,
 * design of experimental systems,
 * technology transfer,
 * knowledge transfer,
 * international scientific exchanges,
 * scientific assesments,
 * contribution to standardization

Headquartered in Rocquencourt, near Paris, INRIA has four Research Centers in
Nancy/Metz, Rennes, Rocquencourt, Sophia Antipolis and a laboratory in
Grenoble.

In 1992, INRIA's personnel numbers about 1200, the permanent staff accounting
for 640. The total budget is about 66 M ECUs (77 M$), 80% of which is the
French Government's subsidy.

To: [email-masked]
Reply-To: [email-masked] (Thomas Skibo)
From: [email-masked] (Thomas Skibo)
Subject: Re: Source Code
Date: Wed, 14 Oct 1992 17:43:50 GMT

I had replied directly to the author on this before I realized that
it was sent to the mailing list so I'll repeat myself in case anybody
cares...

> 
> 
> [email-masked] says:
> 
> | My Net-2 release BSD patch should still be available from uxc.cso.uiuc.edu.
> | 
> | The file you want is "pub/tcplw.shar.Z".  
> | 
> | The patched TCP has been running quite stable on a uVAX at U. of
> | I. for at least 5 months.  There is a minor bug (described in the README)
> | which I've been reluctant to fix because I don't want to redo all
> | the testing that I went through.  It's a one line change.  Also, the
> 
> Did you publish your test plan/methods?
> 
> Thanx in advance,
> 
> Steve Wise.

No, I guess I didn't really go into much detail of my testing methods
when I wrote the tech report.  I did show some graphs that I 
used to verify rtt measurements, though.  They compared rtt measurements
with and without time-stamps.

Window scaling was tested in a variety of ways.  I used ttcp and a tool
I developed for the SGI that would delay and/or randomly drop packets
(it intercepted outgoing packets by changing the if_output pointer in
an ifnet structure).  By delaying ACKs out of the SGI, I could verify
that the uVAX would send over 64K outstanding.  By dropping data segments
out of the SGI, I could verify that the VAX would report the proper
time-stamp echo replies in ACKs (this was tough-- the time-stamp clock
is so slow you have to look for instances where the senders clock ticked
AND a packet was dropped to verify that out-of-order packets didn't
advance the echo replies).

I did a lot of "seat-of-the-pants" testing:  I kludged the SGI so that
the time-stamps would count in increments of 0x1000000 so that I could
test the modulo comparisons.  I would set back the SGI's time-stamp clock
to test packets dropped by PAWs.  I set back the SGI's time-stamp clock
and set forward the VAX's "expire TS.recent" timer to makes sure TS.recent
is thrown away on an idle connection after 24 days.

Two bugs that have been found since then:

	FIN wasn't taken into account when deciding to update TS.recent
	so the last FIN-ACK would make a properly working sender come
	up with a ridiculous rtt measurement if the connection had
	been idle for a while.

	This one's fairly new:  if a connecting TCP reuses an address
	and the receiving TCP is in TIME_WAIT, TCP will close the old
	connection and then jump back in tcp_input() to start over.
	Unfortunately, the options have been discarded by then so then
	window scaling and time-stamping will not work.  I think this
	is probably a problem in unmodified TCP in that the MSS option
	might be thrown away, too.  Tim Seaver at the MCNC Center for
	Communications saw this happening and he had it even worse:
	the fact that the headers are stripped twice in that case
	corrupted his mbufs (he got a negative length and an offset
	that was bigger than MLEN).

-skibo

---
Thomas Skibo
[email-masked]

Date: Wed, 14 Oct 92 10:41:47 -0700
From: [email-masked] (Thomas Skibo)
To: [email-masked] (Steve Wise)
Subject: Re: Source Code
Cc: [email-masked]

I had replied directly to the author on this before I realized that
it was sent to the mailing list so I'll repeat myself in case anybody
cares...

> 
> 
> [email-masked] says:
> 
> | My Net-2 release BSD patch should still be available from uxc.cso.uiuc.edu.
> | 
> | The file you want is "pub/tcplw.shar.Z".  
> | 
> | The patched TCP has been running quite stable on a uVAX at U. of
> | I. for at least 5 months.  There is a minor bug (described in the README)
> | which I've been reluctant to fix because I don't want to redo all
> | the testing that I went through.  It's a one line change.  Also, the
> 
> Did you publish your test plan/methods?
> 
> Thanx in advance,
> 
> Steve Wise.

No, I guess I didn't really go into much detail of my testing methods
when I wrote the tech report.  I did show some graphs that I 
used to verify rtt measurements, though.  They compared rtt measurements
with and without time-stamps.

Window scaling was tested in a variety of ways.  I used ttcp and a tool
I developed for the SGI that would delay and/or randomly drop packets
(it intercepted outgoing packets by changing the if_output pointer in
an ifnet structure).  By delaying ACKs out of the SGI, I could verify
that the uVAX would send over 64K outstanding.  By dropping data segments
out of the SGI, I could verify that the VAX would report the proper
time-stamp echo replies in ACKs (this was tough-- the time-stamp clock
is so slow you have to look for instances where the senders clock ticked
AND a packet was dropped to verify that out-of-order packets didn't
advance the echo replies).

I did a lot of "seat-of-the-pants" testing:  I kludged the SGI so that
the time-stamps would count in increments of 0x1000000 so that I could
test the modulo comparisons.  I would set back the SGI's time-stamp clock
to test packets dropped by PAWs.  I set back the SGI's time-stamp clock
and set forward the VAX's "expire TS.recent" timer to makes sure TS.recent
is thrown away on an idle connection after 24 days.

Two bugs that have been found since then:

	FIN wasn't taken into account when deciding to update TS.recent
	so the last FIN-ACK would make a properly working sender come
	up with a ridiculous rtt measurement if the connection had
	been idle for a while.

	This one's fairly new:  if a connecting TCP reuses an address
	and the receiving TCP is in TIME_WAIT, TCP will close the old
	connection and then jump back in tcp_input() to start over.
	Unfortunately, the options have been discarded by then so then
	window scaling and time-stamping will not work.  I think this
	is probably a problem in unmodified TCP in that the MSS option
	might be thrown away, too.  Tim Seaver at the MCNC Center for
	Communications saw this happening and he had it even worse:
	the fact that the headers are stripped twice in that case
	corrupted his mbufs (he got a negative length and an offset
	that was bigger than MLEN).

-skibo

---
Thomas Skibo
[email-masked]

From: [email-masked] (Steve Wise)
To: [email-masked] (Thomas Skibo)
Cc: [email-masked]
Subject: Re: Source Code 
Date: Wed, 14 Oct 92 10:09:15 -0600

[email-masked] says:

| My Net-2 release BSD patch should still be available from uxc.cso.uiuc.edu.
| 
| The file you want is "pub/tcplw.shar.Z".  
| 
| The patched TCP has been running quite stable on a uVAX at U. of
| I. for at least 5 months.  There is a minor bug (described in the README)
| which I've been reluctant to fix because I don't want to redo all
| the testing that I went through.  It's a one line change.  Also, the

Did you publish your test plan/methods?

Thanx in advance,

Steve Wise.