Bugzilla – Full Text Bug Listing |
Summary: | ARP and Ndisc caches should be updated by receiving valid L3 packets | ||
---|---|---|---|
Product: | ns-3 | Reporter: | Tommaso Pecorella <tommaso.pecorella> |
Component: | internet | Assignee: | Tommaso Pecorella <tommaso.pecorella> |
Status: | RESOLVED FIXED | ||
Severity: | minor | CC: | ns-bugs, ns3, tomh |
Priority: | P5 | ||
Version: | ns-3-dev | ||
Hardware: | All | ||
OS: | All | ||
Attachments: |
patch
TCP flow analysis |
Description
Tommaso Pecorella
2015-02-01 05:35:45 EST
*** Bug 2217 has been marked as a duplicate of this bug. *** Hello Tomasso; regarding Bug #2217, thank you for your comment, I'm happy to work on an improved patch for this bug #2057. Created attachment 2365 [details]
patch
This approach is simple and effective. The only downside is that it *could* have a non-negligible performance hit for nodes that have a lot of entries in their ARP cache.
Created attachment 2366 [details]
TCP flow analysis
A TCP flow pre and post patch according to Wireshark.
(In reply to Tommaso Pecorella from comment #4) > Created attachment 2366 [details] > TCP flow analysis > > A TCP flow pre and post patch according to Wireshark. Do I understand correctly that the improvement is due to avoiding TCP transmission 'pausing' for new request/reply exchanges every so often? If static ARP entries were used, would the same performance improvement be visible? (In reply to Tom Henderson from comment #5) > (In reply to Tommaso Pecorella from comment #4) > > Created attachment 2366 [details] > > TCP flow analysis > > > > A TCP flow pre and post patch according to Wireshark. > > Do I understand correctly that the improvement is due to avoiding TCP > transmission 'pausing' for new request/reply exchanges every so often? If > static ARP entries were used, would the same performance improvement be > visible? Correct. And you could see it on UDP as well (for UDP it takes the form of a sudden drop and a peak afterwards, since packets are buffered and theres no timeout). Static ARP have the very same effect, but (again) the ARP entry "pinning" is confirmed by experiments using 3 Linux boxes (source - router - destination). Until the flow is... flowing, the entry is marked as alive. As soon as the flow stops, the entry timeout kicks in and, after 30 seconds (or the configured timeout) it is marked as invalid and then removed. As a side note: yes, pure unidirectional UDP flows are in trouble even with this patch. Alas, this is normal. (In reply to Tommaso Pecorella from comment #6) > (In reply to Tom Henderson from comment #5) > > (In reply to Tommaso Pecorella from comment #4) > > > Created attachment 2366 [details] > > > TCP flow analysis > > > > > > A TCP flow pre and post patch according to Wireshark. > > > > Do I understand correctly that the improvement is due to avoiding TCP > > transmission 'pausing' for new request/reply exchanges every so often? If > > static ARP entries were used, would the same performance improvement be > > visible? > > Correct. And you could see it on UDP as well (for UDP it takes the form of a > sudden drop and a peak afterwards, since packets are buffered and theres no > timeout). > > Static ARP have the very same effect, but (again) the ARP entry "pinning" is > confirmed by experiments using 3 Linux boxes (source - router - destination). > Until the flow is... flowing, the entry is marked as alive. As soon as the > flow stops, the entry timeout kicks in and, after 30 seconds (or the > configured timeout) it is marked as invalid and then removed. > > As a side note: yes, pure unidirectional UDP flows are in trouble even with > this patch. Alas, this is normal. Agreed; I support merging this patch. changeset: 12073:c2f388ad2677 |