[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-devel] [task #14128] Appropriate byte counting/stretch ACK support

From: Joel Cunningham
Subject: [lwip-devel] [task #14128] Appropriate byte counting/stretch ACK support
Date: Tue, 7 Mar 2017 00:40:01 -0500 (EST)
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0

Follow-up Comment #12, task #14128 (project lwip):

I did some more investigation of NetBSD and it has two sysctl variables that
control ABC, tcp.abc.enable and tcp.abc.aggressive.  With NetBSD 7.0.2, both
of these are set to 1, indicating ABC is on by default and is using an L value
of 2 * SMSS.  Hopefully this is helpful in evaluating what our defaults for
LwIP should be

I have attached a first-round patch of implementing ABC. I've added some
options to control ABC functionality and the limit.  I'm doing some
performance analysis testing now, but the patch should be functionally correct
according to RFC behavior.

I have done a couple of test cases so far, the first is sendmsg test sending
256KB to a Windows 7 receiver.  With ABC, you can see the congestion window is
larger by the end of the transfer.  Strangely, we don't get to see the
advancement during slow start because LwIP is getting stuck with an super low
ssthresh of 8192 when Windows is using receive window auto-tuning.

A second test I've done is run the 'stat' command from the shell which
generates a bunch of telnet data, which ends up generating between 1-2 full
sized segments and some other runt segments.  You can see ABC appropriately
byte counting in this situation

(file #39912, file #39913, file #39914, file #39915)

Additional Item Attachment:

File name: 0001-Add-ABC-support.patch     Size:4 KB
File name: shell-stat-abc-0.txt           Size:1 KB
File name: shell-stat-abc-1-limit-2.txt   Size:1 KB
File name: 256KB-abc-0.txt                Size:4 KB


Reply to this item at:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]