[OPNFLWJAVA-47] TCP Options incorrect Created: 27/Mar/15 Updated: 07/Apr/15 Resolved: 07/Apr/15 |
|
| Status: | Resolved |
| Project: | openflowjava |
| Component/s: | General |
| Affects Version/s: | unspecified |
| Fix Version/s: | None |
| Type: | Bug | ||
| Reporter: | Anton Ivanov | Assignee: | Anton Ivanov |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Operating System: Linux |
||
| External issue ID: | 2905 |
| Description |
|
TCP initializer does not set NO_DELAY option. This has effect across all OS-es, but has especially bad effects on connection latency on Linux with kernel 3.14 and later which does additional aggressive throughput optimizations. This is why I am tagging this for Linux (Ubuntu LTS with updates will default to 3.16). For nearly all openflow use cases openflow should operate in no-delay mode instead of throughput mode. This includes what openflow benchmarks call "throghput" as the actual throughput there is nowhere near what TCP means as throughput optimization. As a result of this option being not set: 1. OS Kernel will try to enqueue multiple frames to merge them into a single packet and wait until another frame is available instead of sending it immediately. 2. OS Kernel will not turn off additional throughput related optmizations (autocork in Linux) which are enabled by default. This is a trivial one-liner, I will send a patch for it later today. |
| Comments |
| Comment by Anil Vishnoi [ 27/Mar/15 ] |
|
master : https://git.opendaylight.org/gerrit/#/c/17213/1 |
| Comment by Anton Ivanov [ 30/Mar/15 ] |
|
Additional offline discussion and inspection of the netty source showed that it presently defaults to having this option on (opposite to OS defaults). This is the correct behavior by design in a double buffering environment. However, in order to ensure that this behavior is correct in the future either for netty or if someone writes a replacement, this should be specified explicitly so that the desired behavior is known (it just will have no effect for now). I am going to drop this to minor now as it effectively documentation, code tidiness and cosmetic at this stage. |
| Comment by Michal Polkorab [ 07/Apr/15 ] |
|
Both changes were merged. |