> That sounds like an option... but is it worth it? Can you give us
> access to your testbench that shows eifel to be an important
> improvement over the current eifel-less stack we have right now? My
> guess is that SACK nullified most of eifel's importance.
SACK doesn't help in the domain whe
On Thu, 12 Apr 2007, LI Xin wrote:
That's disappointing, but better safe than sorry.
BTW. Is there any legal alternative, e.g. make this as an option like
WANT_IDEA?
That sounds like an option... but is it worth it? Can you give us access
to your testbench that shows eifel to be an importa
> BTW. Is there any legal alternative, e.g. make this as an option like
> WANT_IDEA?
I do not know what WANT_IDEA is.
As far as alternatives, there is F-RTO (RFC 4138) and DSACK (RFCs 2883 &
3708). We have also worked on a response that is different (and
unencumbered). It is just an internet-d
Bruce M. Simpson wrote:
> First of all,
>
> Xin: Many thanks for your excellent work on bringing the code up to date.
>
> Mike Silbersack wrote:
>>
>> No. That is not going into FreeBSD if I can help it.
>> http://www.ietf.org/ietf/IPR/ERICSSON-EIFEL
>> On top of that, we don't need yet another
First of all,
Xin: Many thanks for your excellent work on bringing the code up to date.
Mike Silbersack wrote:
No. That is not going into FreeBSD if I can help it.
http://www.ietf.org/ietf/IPR/ERICSSON-EIFEL
On top of that, we don't need yet another complication to the already
too-complex re
On Thu, 12 Apr 2007, LI Xin wrote:
Hi,
I found this by accident on our wiki:
Re-roll and bring in the Eifel detection originally submitted by Jeffrey
Hsu.
No. That is not going into FreeBSD if I can help it.
http://www.ietf.org/ietf/IPR/ERICSSON-EIFEL
On top of that, we don't need yet an
Hi,
I found this by accident on our wiki:
Re-roll and bring in the Eifel detection originally submitted by Jeffrey
Hsu.
* PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/68110
* Eifel detection has the potential to improve network performance,
in those cases where TCP has erroneously