[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 15:55:00 +0100
Thunderbird 220.127.116.11 (X11/20070530)
Kieran Mansley wrote:
>>> On Thu, 2008-10-09 at 09:25 +0100, David Woodhouse wrote:
>>>> Has anyone looked at implementing SACK?
> 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.
I've seen, I think, two attempts at implementing SACK support out there.
Neither were properly contributed IIRC (so it would not be wise, legally,
to just take them) and there were rough edges. A web search could probably
dig out the links. In neither case was the implementation that invasive
really (although it should indeed be optional regardless).
SACK is now a widely used "option", and it is beneficial to small memory
targets as it allows you to free up packet buffers sooner! As such I think
it would be a good fit with lwIP.
eCosCentric Limited http://www.eCosCentric.com/ The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["Si fractum non sit, noli id reficere"]------ Opinions==mine
[lwip-devel] [bug #24493] Dropped incoming packets cause a burst of duplicate ACKs, Bill Auerbach, 2008/10/09