[e2e] Are we doing sliding window in the Internet?

[Lachlan Andrew]

Greetigns Anil,

On 03/01/07, Agarwal, Anil <Anil.Agarwal at viasat.com> wrote:
> I just did a few quick tests with a Linux 2.6.18
> TCP stack over an (emulated) satellite link.
>
> A 50 kbyte transfer finishes in 5 RTTs (including one for the SYN exchange).
> a Sun Solaris 5.8 machine shows the 50 kbyte transfer take 7 RTTs.
>
> 1. Is this what the Linux TCP stack implementors intended? Is this
> documented somewhere?

I can't speak for them, but I would think that speeding up slow start
was their aim, yes.  Google "quickack", or look at  man 7 tcp on a
Linux system.

> 2. Does this violate any IETF TCP principle, in letter or spirit? It seems
> to have an (unfair) advantage over TCP implementations that always perform
> delayed ack.

I personally think it is within the spirit of TCP.   TCP is already
internally unfair (look at "RTT unfairness", or "jumbo-frame
unfairness", which can give speed disparities much greater than 7:5).
The original aim of TCP was a roughly-fair mechanism to achieve good
effective data rates while avoiding congestion collapse.  Speeding up
slow start is an important part of improving the effective data rate.

If absolute equality of rates had been the aim, wouldn't the
algorithms have been specified independently of the MSS, and wouldn't
steps have been taken to avoid RTT-unfairness when it was discovered?

As an aside, I thought of a nice hack which I think is within the
letter of the standards, but well outside the spirit.
1. First packet, send a MSS
2. After the first ACK, send 2MSS worth of 1-byte packets
3. 1 RTT later, receive 1MSS worth of ACKs (ack'ing every second packet)
4. Without ABC, we now have a CWND of 500-1500 packets.

Could someone tell me if this is within the letter of the standards?

Cheers,
Lachlan

-- 
Lachlan Andrew  Dept of Computer Science, Caltech
1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
Phone: +1 (626) 395-8820    Fax: +1 (626) 568-3603