[e2e] Question about RFC 2581

[Henderson, Thomas R]

> > 
> > In fact, I think that one might be able to construct a 
> satellite gateway
> > that maintained true end-to-end semantics (no byte of data 
> acked before
> > the true receiver acked it), and also adhered to the 
> principle of not
> > returning more than one (split) ack for every segment successfully
> > received at the gateway, and approach the performance of 
> TCP-splitting
> > gateways.
> 
> The whole point of RBSCP was to NOT break the E-2-E semantics of
> a connection and at the same time NOT save any state in the routers
> aka no per-flow-state...
> 
> If I grok what you are saying above I don't see how you could
> "speed" the satellite connection up...

I was just suggesting that a gateway that did hold per-flow state
could operate somewhat like a split-connection gateway without 
having to resort to acking segments prematurely.  For example,
the gateway facing the server could hold the first received ack
(for the first full segment of data) and parcel it out to the
server in small chunks.  (assuming it was not a Linux server,
which already uses ABC)

Now, one could certainly split every ack into, say, five acks,
but that could induce TCP-unfriendly behavior.  With a bit of
logic (and conservative behavior) in the gateway, the ack 
splitting could keep the connection TCP-friendly on the 
terrestrial side.  That is, the data transfer would proceed
no more quickly than if the gateway were the actual TCP client.

> 
> Of course all of this only works well if you get the send and receive
> windows up large enough on each side as well.... 

Somewhat true, although receive window values could be manipulated
(but small send buffer size is more problematic).

But my main point was just to note that not all split acks are of
the DoS variety as noted by Savage et al-- not to advocate against
using ABC.  There are probably other vendors too who are obtaining
performance boosts with similar ack manipulations.

Tom