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

From: Ingemar Johansson S <[email-masked]>
Date: Tue, 29 Apr 2014 07:57:34 +0000

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.

/Ingemar

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

Ericsson AB
Wireless Access Networks
Labratoriegränd 11
971 28, Luleå, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289
[email-masked]<mailto:[email-masked]>
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>
=================================

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 29 Apr 2014 08:01:31 +0000

> 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.

> [email-masked]
> www.ericsson.com
>  
> “Those are my principles, and if you don't like them... 
> well, I have others.”  Groucho Marx

-----------------------------------
"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)

---

From: Varun Singh <[email-masked]>
Date: Tue, 29 Apr 2014 11:08:20 +0300

Hi Ingemar,

Thank you for implementing the test cases and providing feedback. more inline.

On Tue, Apr 29, 2014 at 10:57 AM, Ingemar Johansson S
<[email-masked]> wrote:
> 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 intention was to keep some network characteristics common across scenarios.
However, not all

> 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.
>

Yes, I am in favor of removing the additional jitter from the TCP scenarios.

-- 
http://www.netlab.tkk.fi/~varun/

---

From: Ingemar Johansson S <[email-masked]>
Date: Tue, 29 Apr 2014 08:59:27 +0000

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:[email-masked]]
Sent: den 29 april 2014 10:02
To: Ingemar Johansson S
Cc: rmcat WG ([email-masked]); Erlendur Karlsson; Zaheduzzaman Sarker; [email-masked]; 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 <[email-masked]<mailto:[email-masked]>> wrote:

Hi

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

Ericsson AB
Wireless Access Networks
Labratoriegränd 11
971 28, Luleå, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289
[email-masked]<mailto:[email-masked]>
www.ericsson.com<x-msg://85/www.ericsson.com>

---

From: Zaheduzzaman Sarker <[email-masked]>
Date: Wed, 30 Apr 2014 11:50:17 +0000

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 ([email-masked]); Erlendur Karlsson; Zaheduzzaman Sarker; [email-masked]; 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

/Ingemar

From: Fred Baker (fred) [mailto:[email-masked]]
Sent: den 29 april 2014 10:02
To: Ingemar Johansson S
Cc: rmcat WG ([email-masked]<mailto:[email-masked]>); Erlendur Karlsson; Zaheduzzaman Sarker; [email-masked]<mailto:[email-masked]>; 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

/Ingemar

Ericsson AB
Wireless Access Networks
Labratoriegränd 11
971 28, Luleå, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289

---

From: Ingemar Johansson S <[email-masked]>
Date: Wed, 30 Apr 2014 12:46:33 +0000

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 ([email-masked]); Erlendur Karlsson; [email-masked]; 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,

Zahed

Hi Fred

/Ingemar

Hi

/Ingemar

Ericsson AB
Wireless Access Networks
Labratoriegränd 11
971 28, Luleå, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 30 Apr 2014 17:02:30 +0000

> 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?

Packet reordering, loss, and duplication happen. Where and to what degree is a question of the structure of networks that packets pass through and what happens in those networks. The last time I know of someone doing an actual measurement and reporting the results was rather a while ago, but it said that at that time about 5% of arriving traffic was reordered. For systemic reasons, I would imagine this is reduced, and very dependent on what networks and types of networks are crossed.

Going out on a limb a bit (this is what I suspect, not what I know), I would imagine that today there are three major sources of traffic reordering. One is loss; in radio networks (which include 3g/etc but also include 802.11, 802.15, and 802.16), loss and retransmission are pretty common. It would be interesting to have someone write a paper measuring and analyzing the resultant “best effort” behaviors in those networks. Another is load balancing in the network; while it is common for ECMP routing to send a subset of flows one way and another subset on another, some networks schedule packets on the most available bandwidth or go round robin. That is a recipe for reordering. The other has to do with adaptive bitrate video and services that deliver it by literally duplicating data. In these services, there is a path from the CDN to the consumer that consists of two disjoint paths. The TCP originator is configured with a link layer multicast address for its first hop router, and there are in fact two such routers, one on each of the parallel paths. The packets don’t arrive at the endpoint, but they do arrive at a point just before it, and the first of each pair of packets to arrive is forwarded to the endpoint. You can imagine that the collection point sees frequent duplication and some degree of reordering.

The single biggest source of reordering, I will postulate, is none of those; it is the result of loss due to TCP’s AIMD behavior. When a packet is dropped in flight due to queue depth or delay, the rest of the packets in that RTT arrive before it, and then its retransmission arrives. Voila! Packet reordering.

Should TCP handle packet reordering? Yes, of course. Making packet arrival sequence completely random will certainly test that behavior; we could discuss the beneficial effects of running TCP over CSNET in the 1980’s and the resulting hardening of TCP’s algorithms. That doesn’t make that level of reordering a valid simulation of the Internet. A more valid simulation will have one or both of two characteristics - that a packet is dropped, the remaining packets in that RTT pass it, and then it arrives, or that packets frequently arrive disordered but to a degree that doesn’t trigger TCP’s Fast retransmit algorithm.

---

From: Colin Perkins <[email-masked]>
Date: Wed, 30 Apr 2014 13:51:36 -0400

> 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?

One of my students collected some UDP streaming measurements from our university to hosts on residential networks, covering all the main UK ISPs, a couple of years ago. With everything using wired connections and UDP we saw a couple of hundred packets delivered out of order, from ~250 million packets sent. I can dig into the details of the re-ordering patterns if there’s interest. We didn’t analyse them too closely at the time because packet loss and delay spikes were much more common.

Colin

-- 
Colin Perkins
http://csperkins.org/