[e2e] Are we doing sliding window in the Internet?
ian.mcdonald at jandi.co.nz
Wed Jan 3 13:15:43 PST 2007
On 1/3/07, Lachlan Andrew <lachlan.andrew at gmail.com> wrote:
> 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
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
I agree that ABC has some problems. Solution is good, implementation
is just horrible :-)
More information about the end2end-interest