TCP flow analysis - wifi multihop network problem

[Marco Mezzavilla]

Dear ns3-users&developers,

I can't understand why, sometimes, a TCP-ACK correctly received by a mid-node of a 5-hop network, is not enqueued in its corresponding transmission queue (not saturated, I checked), thus triggering a RTO expiration. Is there any reason why this may happen?

I tried to run the same scenario with different seeds; for simulation times of 100 seconds, this behavior occurs once or twice.  

I really need to understand if this is a reasonable behavior, or it is a BUG.

The scenario is the following:

one source node transmits TCP packets via bulk-send-application to a destination node that is 5 hops away (CHAIN topology).

(source)1 ---> 2 ---> 3 ---> 4 ---> 5 ---> 6(destination) 

Network configuration:

- Wifi 802.11a

- TCP NewReno

- Fixed positions (100 meters inter-node distance)

- OLSR

Any input would be very useful. 

Thanks in advance,

-- 
Marco Mezzavilla
Ph.D. Student - SIGNET Group
Department of Information Engineering (DEI)
University of Padova - Italy

[John Abraham]

sometimes I use NetAnim's packet filter to see if the desired ack reached a node. see attached picture.

  AnimationInterface anim("large.xml");

  anim.EnablePacketMetadata(true);

in any case how did you confirm that ACK=X reached Node A but not forwarded to Node B? 

--
You received this message because you are subscribed to the Google Groups "ns-3-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/ns-3-users/-/zStEPeUmxOkJ.
To post to this group, send email to ns-3-...@googlegroups.com.
To unsubscribe from this group, send email to ns-3-users+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ns-3-users?hl=en.

[Marco Mezzavilla]

Hi John,

thanks for replying. 

I am sure that Node A correctly received ACK=X but not forwarded to Node B because I'm generating a .txt file for each node, where I print the WiFi MAC queue (time - Qsize - src - dst - seqnum - ack), called in WifiMacQueue::Enqueue, and the correctly received packets (time - seqnum - ack - pck_size), called in YansWifiPhy::EndReceive, when PER check is passed.

I will give it a try with NetAnim, but I expect this to confirm the trends I found with my .txt traces.

Regards,
Marco

[Nicola Baldo]

Hi Marco,

On Thursday, May 17, 2012 6:04:07 PM UTC+2, Marco Mezzavilla wrote:

I am sure that Node A correctly received ACK=X but not forwarded to Node B because I'm generating a .txt file for each node, where I print the WiFi MAC queue (time - Qsize - src - dst - seqnum - ack), called in WifiMacQueue::Enqueue, and the correctly received packets (time - seqnum - ack - pck_size), called in YansWifiPhy::EndReceive, when PER check is passed.

this is not very clear to me, how do you detect that one packet seen upon EndReceive corresponds to another packet seen upon Enqueue?

Nicola

[Marco Mezzavilla]

Hi Nicola,

I can see that ACK=X received by Node 4 is enqueued in its associated MAC queue after correct reception by simply watching my .txt files. This is possible because I store 'ack' and 'seqnum' of all the received packets (YansWifi) and all the packet-to-be-transmitted (wifiMacQueue).

Thus, if Node 4 received ACK=X at time Y, I (should always) find ACK=X in Node 4 Wifi MAC queue at time Y+delta.

But this is not always true, I don't know why.

Marco

--
You received this message because you are subscribed to the Google Groups "ns-3-users" group.

To view this discussion on the web visit https://groups.google.com/d/msg/ns-3-users/-/HPxffYsdzLIJ.

To post to this group, send email to ns-3-...@googlegroups.com.
To unsubscribe from this group, send email to ns-3-users+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ns-3-users?hl=en.

[Nicola Baldo]

Hi Marco,

On Thursday, May 17, 2012 6:53:22 PM UTC+2, Marco Mezzavilla wrote:

I can see that ACK=X received by Node 4 is enqueued in its associated MAC queue after correct reception by simply watching my .txt files. This is possible because I store 'ack' and 'seqnum' of all the received packets (YansWifi) and all the packet-to-be-transmitted (wifiMacQueue).

you are talking about TCP ACKs and sequence numbers, right?

Nicola

[Marco Mezzavilla]

Yes.

In a while I will send you NetAnim png figures proving what I said.

--
You received this message because you are subscribed to the Google Groups "ns-3-users" group.

To view this discussion on the web visit https://groups.google.com/d/msg/ns-3-users/-/Lnd2mMvat9wJ.

To post to this group, send email to ns-3-...@googlegroups.com.
To unsubscribe from this group, send email to ns-3-users+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ns-3-users?hl=en.

[Marco Mezzavilla]

Hi John, Nicola, all,

as I expected, by using NetAnim I confirm the trend I noted with my txt files tracking system.

I recall the topology:

(source)0 ---> 1 ---> 2 ---> 3 ---> 4 ---> 5(destination)

Node 3 received ACK from Node 4, as shown in (1), BUT it does not forward it to Node 2, as shown in (2).

(1) SHOW that Node 3 correctly received ACK=2431273 from Node 2 ----- refer to 1.png (from4 ---> to3)

(2) SHOW that Node 3 does not forward the correctly received ACK=2431273 ---- refer to 2.png (from3 --> to2)

I also attach a file (Node_3_Transmissions.txt) where you can better see what happened before, and after that critical point.

You can easily find that Node 3 stops sending ACK for few seconds. 

After 4 retransmissions, between 46 and 55 seconds, it starts again sending ACKs (not the one missed before...).

In file Node_3_Receptions.txt instead you can see how the TCP ACKs are correctly received (but not forwarded -see Node_3_Transmissions). 

Doea anybody have an idea of what is going on?

Thanks in advance,
Marco

[John Abraham]

Actually to clarify NetAnim reports packets only if from Node and to Node have both seen the packet. So according to 2.png. Node 2 indeed received the ACK.

In fact NetAnim records a packet only after the rx event at the "To Node". can you share the xml?

[Marco Mezzavilla]

I attached '1.png' to show that Node 3 received ACK=X.

I attached '2.png' to show that Node 3 does not forward ACK=X.

The xml is 86 MB....

[John Abraham]

2.png shows that Node 3 sent the Ack to Node 2 and node 2 received it. The very fact that this row is showing up in the table indicated Node 2 received it, because NetAnim records packets only after the rxevent at the destination node happened.

Try to see if this ACK is present between From Node == 2 to to Node == 1, if not, it means Node 2 dropped it (it does not mean Node 3 did not forward it).

[John Abraham]

even if you zip compress the file is it large?

[Marco Mezzavilla]

Ok, I see what you meant.

Anyway, to confirm what I say you can see Node_3_Transmissions.txt.

Here, the latest ACK (size 76) transmitted by Node 3 is ACK=2430737 (as confirmed by 2.png).

This means that Node 2 is not receiving ACK=2431273 because Node 3 did not even try to forward, that is the problem I originally mentioned.

For the xml, please try: 

hg clone https://bitbucket.org/mezza84/mm_files

Thanks for your support,

Marco

[John Abraham]

Yes, indeed, that segment is dropped at 3. Have you tried checking if a route exists from node 3 at that time? 

i.e at SimulationTime >= 45 and SimulationTime <= 47 PrintRoutingtable in 

Forward function at Ipv4L3Protocol.cc

[John Abraham]

Forgot to mention you could enable logging for "Ipv4L3Protocol"  , and also check if the routing table is correct during 45s to 47s. You could do SimulatorSchedule for that time and print the tables. 

Further, AnimationInterface has SetStartTime and SetEndTime to restrict the window of tracing to generate smaller , manageable xml.

[Marco Mezzavilla]

Hey John,

thanks for the input, I will try to focus on the IP level.

Regards,

Marco

[John Abraham]

you could also Print the packet's meta data at 

Ipv4L3Protocol::IpForward (Ptr<Ipv4Route> rtentry, Ptr<const Packet> p, const Ipv4Header &header)

after checking m_node->GetId () == 3 , to see if the packet reached Node 3's forwarding logic.

Enable Packet metadata globally

     Packet::EnablePrinting ();

and after getting the packet Ptr in IpForward, print it

  std::ostringstream oss;

  p->Print (oss);

 NS_LOG_UNCOND( oss.str ());

[Marco Mezzavilla]

Hi John,

the problem is on the IP route tables, as you suggested.

In the following, please find the routing tables of each node at time 45.6.

As you can note, Node 3 does not 'see' Node 0.

NODE 0 

Destination   NextHop        Interface    Distance
10.1.1.2        10.1.1.2        1        1    
10.1.1.3        10.1.1.2        1        2    
10.1.1.4        10.1.1.2        1        3    
10.1.1.5        10.1.1.2        1        4    
10.1.1.6        10.1.1.2        1        5    

NODE 1

Destination   NextHop        Interface    Distance
10.1.1.1        10.1.1.1        1        1    
10.1.1.3        10.1.1.3        1        1    
10.1.1.4        10.1.1.3        1        2    
10.1.1.5        10.1.1.3        1        3    
10.1.1.6        10.1.1.3        1        4    

NODE 2
Destination   NextHop        Interface    Distance
10.1.1.1        10.1.1.2        1        2    
10.1.1.2        10.1.1.2        1        1    
10.1.1.4        10.1.1.4        1        1    
10.1.1.5        10.1.1.4        1        2    
10.1.1.6        10.1.1.4        1        3    

NODE 3

Destination   NextHop        Interface    Distance
10.1.1.2        10.1.1.3        1        2    
10.1.1.3        10.1.1.3        1        1    
10.1.1.5        10.1.1.5        1        1    
10.1.1.6        10.1.1.5        1        2    

NODE 4

Destination   NextHop        Interface    Distance
10.1.1.1        10.1.1.4        1        4    
10.1.1.2        10.1.1.4        1        3    
10.1.1.3        10.1.1.4        1        2    
10.1.1.4        10.1.1.4        1        1    
10.1.1.6        10.1.1.6        1        1    

NODE 5

Destination   NextHop        Interface    Distance
10.1.1.1        10.1.1.5        1        5    
10.1.1.2        10.1.1.5        1        4    
10.1.1.3        10.1.1.5        1        3    
10.1.1.4        10.1.1.5        1        2    
10.1.1.5        10.1.1.5        1        1

Later routing tables (time 46.4) show that also Node 4 and Node 5 stops having routing information about Node 0.

NODE 0

Destination   NextHop        Interface    Distance
10.1.1.2        10.1.1.2        1        1    
10.1.1.3        10.1.1.2        1        2    
10.1.1.4        10.1.1.2        1        3    
10.1.1.5        10.1.1.2        1        4    
10.1.1.6        10.1.1.2        1        5    

NODE 1
Destination   NextHop        Interface    Distance
10.1.1.1        10.1.1.1        1        1    
10.1.1.3        10.1.1.3        1        1    
10.1.1.4        10.1.1.3        1        2    
10.1.1.5        10.1.1.3        1        3    
10.1.1.6        10.1.1.3        1        4    

NODE 2
Destination   NextHop        Interface    Distance
10.1.1.1        10.1.1.2        1        2    
10.1.1.2        10.1.1.2        1        1    
10.1.1.4        10.1.1.4        1        1    
10.1.1.5        10.1.1.4        1        2    
10.1.1.6        10.1.1.4        1        3    

NODE 3
Destination   NextHop        Interface    Distance
10.1.1.2        10.1.1.3        1        2    
10.1.1.3        10.1.1.3        1        1    
10.1.1.5        10.1.1.5        1        1    
10.1.1.6        10.1.1.5        1        2    

NODE 4

Destination   NextHop        Interface    Distance
10.1.1.2        10.1.1.4        1        3    
10.1.1.3        10.1.1.4        1        2    
10.1.1.4        10.1.1.4        1        1    
10.1.1.6        10.1.1.6        1        1    

NODE 5

Destination    NextHop        Interface    Distance
10.1.1.2        10.1.1.5        1        4    
10.1.1.3        10.1.1.5        1        3    
10.1.1.4        10.1.1.5        1        2    
10.1.1.5        10.1.1.5        1        1

At around 50 seconds, the routing tables are again complete.

Please note that I am using OLSR routing, with its default configuration. 

Does anybody have an idea why this happen?

As I said, by evaluating 100s-long simulations with different seeds, it occur 2/3 times...

Thanks in advance for the support.

BR,

Marco

[John Abraham]

Well, intuitively this should not happen for stationary nodes at all. I don't know much about OLSR , so I will leave it to the experts. Perhaps you could start a new thread with appropriate subject adding OLSR.

[Marco Mezzavilla]

Exactly...

I'll start a new thread, thanks for your support John.

Regards,
Marco