[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-devel] [bug #24493] Dropped incoming packets cause a burst of
Re: [lwip-devel] [bug #24493] Dropped incoming packets cause a burst of duplicate ACKs
Thu, 09 Oct 2008 11:26:10 +0100
On Thu, 2008-10-09 at 11:11 +0100, David Woodhouse wrote:
> On Thu, 2008-10-09 at 10:43 +0100, Kieran Mansley wrote:
> > On Thu, 2008-10-09 at 09:25 +0100, David Woodhouse wrote:
> > > On Thu, 2008-10-09 at 08:17 +0000, Kieran Mansley wrote:
> > > > the sender doesn't know that we've buffered some of the frames after
> > > > the original loss, and so sends them all again.
> > >
> > > So why don't we tell it? :)
> > >
> > > Has anyone looked at implementing SACK?
> > It's simply a case of a trade off with code size and computation that
> > doesn't fit well with the goals of lwIP.
> Even as an option? Is SACK really that complicated?
As an option it would be possible, and if someone wanted to implement it
in that way I wouldn't stop them. I am wary however of ending up with
too many optional blocks of code, particularly those that aren't used by
active developers, as they tend to rot.
But yes, SACK is pretty complex compared to TCP (another way of putting
this is that TCP as a base protocol is pretty simple) and it would add a
fair bit of extra code to both send and receive SACK options and deal
with them appropriately. At the moment the level of option we support
for loss is should we even buffer out of order packets at all. SACK is
quite a level of sophistication above that rather crude approach.
[lwip-devel] [bug #24493] Dropped incoming packets cause a burst of duplicate ACKs, Bill Auerbach, 2008/10/09