Bug 2057 - ARP and Ndisc caches should be updated by receiving valid L3 packets
ARP and Ndisc caches should be updated by receiving valid L3 packets
Status: RESOLVED FIXED
Product: ns-3
Classification: Unclassified
Component: internet
ns-3-dev
All All
: P5 minor
Assigned To: Tommaso Pecorella
:
: 2217 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2015-02-01 05:35 EST by Tommaso Pecorella
Modified: 2016-04-04 16:24 EDT (History)
3 users (show)

See Also:


Attachments
patch (20.83 KB, patch)
2016-04-02 15:50 EDT, Tommaso Pecorella
Details | Diff
TCP flow analysis (59.29 KB, image/jpeg)
2016-04-02 16:05 EDT, Tommaso Pecorella
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tommaso Pecorella 2015-02-01 05:35:45 EST
Both caches should have their entries updated by "successful" packets received/sent by L4.
As an example, if TCP receives an ACK or a data packet from IP X, the ARP / NDISC cache entry should be refreshed. Same for UDP or any other L4 protocol (we should check the RFC for ICMP but I think it applies to that too).
Comment 1 Tommaso Pecorella 2015-11-13 16:50:07 EST
*** Bug 2217 has been marked as a duplicate of this bug. ***
Comment 2 Chip Webb 2015-11-13 22:30:40 EST
Hello Tomasso; regarding Bug #2217, thank you for your comment, I'm happy to work on an improved patch for this bug #2057.
Comment 3 Tommaso Pecorella 2016-04-02 15:50:35 EDT
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.
Comment 4 Tommaso Pecorella 2016-04-02 16:05:12 EDT
Created attachment 2366 [details]
TCP flow analysis

A TCP flow pre and post patch according to Wireshark.
Comment 5 Tom Henderson 2016-04-04 13:05:06 EDT
(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?
Comment 6 Tommaso Pecorella 2016-04-04 13:13:55 EDT
(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.
Comment 7 Tom Henderson 2016-04-04 13:58:49 EDT
(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.
Comment 8 Tommaso Pecorella 2016-04-04 16:24:48 EDT
changeset:   12073:c2f388ad2677