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

[Ian McDonald]

On 1/3/07, Lachlan Andrew <lachlan.andrew at gmail.com> wrote:
> Greetings,
>
> This is probably not related to the original thread (on what happens
> in real networks, as distinct from what *should* happen), but the word
> "bug" bugged me...
>
> On 02/01/07, Joe Touch <touch at isi.edu> wrote:
> >
> > ABC is EXPERIMENTAL.
>
> Fair enough.  I've just noticed that the default in 2.6.18 has been
> changed to "off", possibly as a result of their experiments :)
>
Yes - see http://www.google.com/custom?domains=www.spinics.net&q=%22high+latency+with+tcp+connections%22&sa=Search&sitesearch=www.spinics.net&client=pub-3422782820843221&forid=1&ie=ISO-8859-1&oe=ISO-8859-1&cof=GALT%3A%23003324%3BGL%3A1%3BDIV%3A%2373B59C%3BVLC%3AFF6600%3BAH%3Acenter%3BBGC%3AC5DBCF%3BLBGC%3A66CC99%3BALC%3A330033%3BLC%3A330033%3BT%3A000000%3BGFNT%3A333300%3BGIMP%3A333300%3BFORID%3A1%3B&hl=en--

The thread is messy though so here is probably the most relevant part:

Main message is from Dave Miller replying to Stephen Hemminger

> On Fri, 1 Sep 2006 01:46:35 +0400
> Alexey Kuznetsov <kuznet at ms2.inr.ac.ru> wrote:
>
> > > Expecting any performance with one byte write's is silly.
> >
> > I am not sure why you are so confident about status of ABC.
> > I missed the discussions, when it was implemented. Apparently,
> > it was noticed that ABC in its pure form does not make sense
> > with snd_cwnd counted in packets and there were some reasons,
> > why it still was not adapted.
>
> I implemented it but don't think ABC is the correct thing to be doing
> in all cases.
>
> If you read the RFC3465, the problem it is trying to address is that of
> small packets causing growth of congestion window beyond the capacity
> of the link.
>
> It makes a number of assumptions that may not be true for Linux:
>   * ABC doesn't take into account congestion window validation RFC2861
>     already prevents most of the problem of inflated growth.
>   * ABC assumes that the "true" capacity of the link is limited by
>     byte count not packet count.

It seems to me that the thing gained by ABC are twofold:

1) protection against ACK division
2) a way to take delayed ACKs into account for cwnd growth

Both of which can be obtained by simply validating the ACK
against the retransmit queue, returning number of true
packets ACK'd.

I would even go so far as to suggest that we should drop ACKs which do
not fall on packetization boundaries.  Perhaps only when not in LOSS
state, but I doubt that this matters in practice.

Cases where mid-packet ACK is valid are truly marginal ones involving
repacketization wrt. MSS/MTU changes, and these would self-correct
eventually.

I agree that ABC has some problems.  Solution is good, implementation
is just horrible :-)