Re: [rmcat] draft-sarker-rmcat-eval-test-00, test case 4.4 RMCAT Flow competing with a long TCP Flow

[Ingemar Johansson S <[e-mail]>]

Hi

Packet reordering can happen in 3G network due to load balancing, I've see examples of this in wireshark logs. Most often it only generate one duplicate ACK in TCP which is normally nothing that triggers fast retransmit and CWND reduction.
The kind of reordering in testcases 4.4 and 4.5 which causes the kind of degraded FTP throughput that I see in the simulations should be very uncommon though.

/Ingemar

From: Zaheduzzaman Sarker
Sent: den 30 april 2014 13:50
To: Ingemar Johansson S; Fred Baker (fred)
Cc: rmcat WG ([e-mail]); Erlendur Karlsson; [e-mail]; Michael Ramalho (mramalho); Xiaoqing Zhu (xiaoqzhu)
Subject: RE: [rmcat] draft-sarker-rmcat-eval-test-00, test case 4.4 RMCAT Flow competing with a long TCP Flow

Hi Fred and Ingemar,

Are you saying re-ordering is not a phenomena that we can observe in the current Internet? And we should not have test cases to handle re-ordering of packets in RMCAT?
BR

Zahed

From: Ingemar Johansson S
Sent: den 29 april 2014 10:59
To: Fred Baker (fred)
Cc: rmcat WG ([e-mail]<mailto:[e-mail]>); Erlendur Karlsson; Zaheduzzaman Sarker; [e-mail]<mailto:[e-mail]>; Michael Ramalho (mramalho); Xiaoqing Zhu (xiaoqzhu)
Subject: RE: [rmcat] draft-sarker-rmcat-eval-test-00, test case 4.4 RMCAT Flow competing with a long TCP Flow

Hi Fred
You are right, it should actually be a FIFO queue involved in the random delay, I asked about this internally and the impression then was that we should allow for reordering to happen, did not think about the TCP problem then though....
In any case if a random delay is still used for test case 4.4 and 4.5 then it could be good to clarify this.

/Ingemar

From: Fred Baker (fred) [mailto:[e-mail]]
Sent: den 29 april 2014 10:02
To: Ingemar Johansson S
Cc: rmcat WG ([e-mail]<mailto:[e-mail]>); Erlendur Karlsson; Zaheduzzaman Sarker; [e-mail]<mailto:[e-mail]>; Michael Ramalho (mramalho); Xiaoqing Zhu (xiaoqzhu)
Subject: Re: [rmcat] draft-sarker-rmcat-eval-test-00, test case 4.4 RMCAT Flow competing with a long TCP Flow


On Apr 29, 2014, at 3:57 AM, Ingemar Johansson S <[e-mail]<mailto:[e-mail]>> wrote:

Hi

I am experimenting  with the bottleneck test cases and found an issue with the competing TCP flows test case.

This test case specifes a Maximum end to end jitter = 30ms. This is implemented as a uniform [0-30ms] random delay in my simulator setup.
The problem with this is that it creates so much reordering that TCP will trigger CWND reduction, and I guess this is not the intention or ?

My recommendation is that we should remove the random delay completely in this test case (and also in 4.5)  as the FTP will introduce plenty of jitter anyhow.

That's the problem with simulations; you really have to think about how to make them similar to whatever they are simulating. Network gear rarely uses non-FIFO queues; even when we have parallel queues for various classes of traffic, the sub-queues are FIFO.

If your simulated queuing system isn't FIFO, its results don't tell us much about what rmcat will do in real networks.

/Ingemar

=================================
Ingemar Johansson  M.Sc.
Senior Researcher

Ericsson AB
Wireless Access Networks
Labratoriegränd 11
971 28, Luleå, Sweden
Phone [phone]
SMS/MMS [phone]
[e-mail]<mailto:[e-mail]>
www.ericsson.com<x-msg://85/www.ericsson.com>

"Those are my principles, and if you don't like them...
well, I have others."  Groucho Marx<http://www.brainyquote.com/quotes/authors/g/groucho_marx.html>
=================================

-----------------------------------
"We are learning to do a great many clever things...The next great task
will be to learn not to do them."

- G. K. Chesterton (1874-1936)