Bug 1109

Summary: ARP silently drops packets when waiting for an ARPreply
Product: ns-3 Reporter: Tommaso Pecorella <tommaso.pecorella>
Component: internetAssignee: ns-bugs <ns-bugs>
Status: RESOLVED FIXED    
Severity: minor CC: tomh
Priority: P5    
Version: ns-3-dev   
Hardware: All   
OS: All   
Attachments: Doc update to point out common mistakes

Description Tommaso Pecorella 2011-04-20 20:44:54 UTC 
It might as well be the "normal" behaviour, but it can be still puzzling.

When an ARP cache is invalid (or null) the packets are queued until the cache is filled.

At the moment the cache size is 3, so if you send more than 3 consecutive packets, only the first 3 will be send and the others will be dropped.

This can be quite rare if an application sends "normal" packets, as it's quite unlikely to queue a batch of more than 3 packets.

On the other hand if you send a single UDP packet large enough (let's say 5000 bytes) on a csma interface it will be fragmented in 4 chunks, with the 4th dropped by ARP.

Now, IP don't have any way to tell if the ARP cache is full, so there's no way to queue the fragments at IP level either.

Possible solutions:
1) increase the ARP cache to ceil (MAX_IP_SIZE / MTU)
2) add a feedback to confirm that the packet hasn't been lost in ARP (interface->IsReady() ?)
3) make it easier to change the "PendingQueueSize" arp attribute.

I know the packet could be still lost in the csma device (retransmit exceeded), but that's usually due to network congestion, so it's more logical.

T.

PS: I'm talking about IPv4, of course.

PS2: yes, IPv4 fragmentation is implemented.
Comment 1 Tommaso Pecorella 2012-01-25 18:42:11 UTC 
Created attachment 1310 [details]
Doc update to point out common mistakes

I don't like open bugs, so I checked out again this one. It seems that's more a documentation flaw rather than a real bug or misbehavior.

Now, I'd like to add the attached paragraph to the "internet-stack.rst" to fill the gap.

Of course this "fix" does assume that people DO read the documentation... which is basically always false. Still, we'll be able to answer politely "RTD" (Read The Documentation), or something less polite.
Comment 2 Tom Henderson 2012-01-26 00:52:19 UTC 
(In reply to comment #1)
> Created attachment 1310 [details]
> Doc update to point out common mistakes
> 
> I don't like open bugs, so I checked out again this one. It seems that's more a
> documentation flaw rather than a real bug or misbehavior.
> 
> Now, I'd like to add the attached paragraph to the "internet-stack.rst" to fill
> the gap.
> 
> Of course this "fix" does assume that people DO read the documentation... which
> is basically always false. Still, we'll be able to answer politely "RTD" (Read
> The Documentation), or something less polite.

ok
Comment 3 Tommaso Pecorella 2012-01-28 19:16:39 UTC 
Updated the documentation about this behavior.

changeset 7699 - 90904c14135f