Subject: RFC implementations

From: "bc azur" <[email-masked]>
Date: Thu, 23 Dec 1999 12:01:14 +0100 (MET)

Dear colleagues, 
I have recently been involved in enhancing TCP for high speed satellite 
communications  and I would like to know the state of art in the field 
of RFC implementations. I know that there have been implementations of 
RFC 1323 and 2018 and 2001. Does any one have some view graphs showing 
the real benefits of these RFC implementations and the conditions it has
 been realized. For 1323 it's immediate but for the other RFC it's 
difficult to quantify. Besides these RFC's what are those likely to be 
normalized. I am actually working for a small company specialized in 
protocol evaluation.
Many thanks 
bc

---

From: "bc azur" <[email-masked]>
Date: Thu, 23 Dec 1999 19:20:26 +0100 (MET)

I know actually the performance of 1323 but my question is as follows:
does any one have done some tests on RFC 2001 and 2018 specifically to 
evaluate the gain or are there publications on this topic comparing the 
different enhancement and their evaluations. For 1323 I know this 
formula and I have tested window size variation.

>It's actually very simple to explain how RFC1323 helps.  It can be
>summarized as:
>
>	        WINDOW SIZE
>Throughput = --------------  upto the actual bandwidth minus proto oh
>	       ROUNDTRIP TIME
>
>I have been able to push data at 98+% of available theoretical 
bandwidth
>over high
>delay.
>
>GReg
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]On
>Behalf Of bc azur
>Sent: Thursday, December 23, 1999 5:01 AM
>To: [email-masked]
>Subject: RFC implementations
>
>
>Dear colleagues,

---

From: Mark Allman <[email-masked]>
Date: Tue, 28 Dec 1999 09:27:51 -0500

> I know that there have been implementations of RFC 1323 and 2018
> and 2001. Does any one have some view graphs showing the real
> benefits of these RFC implementations and the conditions it has
> been realized.

RFC 1323 provides larger windows that allow TCP to fully utilize a
long-delay pipe.

RFC 2018 provides the information about exactly which segments have
arrived and which have not.  This allows a TCP sender to obey
congestion signals, but not back off to a 1 segment window when
multiple segments are lost.

RFC 2001 is obsolete.  RFC 2581 is the current version.  That RFC
really provides no performance gain to a single flow (OK, fast
retransmit and fast recovery are gains over taking timeouts).
Rather, that document outlines the congestion control mechanisms
that everyone must follow so the network does not collapse, causing
everyone to get little or no performance.

The two documents produced by the tcpsat WG have more verbose
descriptions and many pointers to the literature.  I suggest reading
RFC 2488 and draft-ietf-tcpsat-res-issues-12.txt (currently in the
RFC Editor's queue).

Happy Holidays!

allman

---
http://roland.grc.nasa.gov/~mallman/