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

Randell Jesup <randell-ietf@jesup.org> Fri, 02 May 2014 09:50 UTC

Return-Path: <randell-ietf@jesup.org>
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 076B11A09D4 for <rmcat@ietfa.amsl.com>; Fri, 2 May 2014 02:50:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level:
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WdKxyuN2sxCP for <rmcat@ietfa.amsl.com>; Fri, 2 May 2014 02:50:23 -0700 (PDT)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 339881A09A6 for <rmcat@ietf.org>; Fri, 2 May 2014 02:50:23 -0700 (PDT)
Received: from pool-71-175-4-197.phlapa.fios.verizon.net ([71.175.4.197]:3985 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <randell-ietf@jesup.org>) id 1WgA6m-000ByR-CQ for rmcat@ietf.org; Fri, 02 May 2014 04:50:20 -0500
Message-ID: <53636A1C.4090501@jesup.org>
Date: Fri, 02 May 2014 05:49:16 -0400
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: rmcat@ietf.org
References: <81564C0D7D4D2A4B9A86C8C7404A13DA31F5BD0F@ESESSMB205.ericsson.se> <F399C574-037C-4F74-80D6-4639FC529C56@cisco.com> <81564C0D7D4D2A4B9A86C8C7404A13DA31F5BDA6@ESESSMB205.ericsson.se> <E0F7A68B07B53F4FBD12DABD61CBA90E126F127F@ESESSMB307.ericsson.se> <7AC92FFB-76BE-494E-86E4-368BB0B6223C@csperkins.org>
In-Reply-To: <7AC92FFB-76BE-494E-86E4-368BB0B6223C@csperkins.org>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org
Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/tc9cpWoWVMtx7m99Sa_hVjsGxTw
Subject: Re: [rmcat] draft-sarker-rmcat-eval-test-00, test case 4.4 RMCAT Flow competing with a long TCP Flow
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." <rmcat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rmcat>, <mailto:rmcat-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rmcat/>
List-Post: <mailto:rmcat@ietf.org>
List-Help: <mailto:rmcat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rmcat>, <mailto:rmcat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 May 2014 09:50:27 -0000

On 4/30/2014 1:51 PM, Colin Perkins wrote:
> On 30 Apr 2014, at 07:50, Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com> wrote:
>> 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.

Having it not fall over on (some) reordering: good.  My experience has 
been only specific unusual network/hardware situations cause more than 
0.0x% reordering of packet delivery (at the IP level, ignoring things 
like TCP retransmit, which is not an IP-level reordering in the way I'm 
discussing).

I've seen significant reordering only on a network (an old office 
network of mine!) where we had multiple bonded T1's and the packets went 
across one of them randomly (I presume).  I think I got to 
low-single-digit percent or more likely 0.n% (like 0.1-0.9%) reordered.  
There may also be some wireless networks where this is more likely than 
on normal wired; I haven't noticed it on WiFi though.

It's easy to accidentally set up DummyNet/etc to cause massive packet 
reordering, however.  I do not think that should be a primary or even 
secondary testcase, and (to be honest) I don't think we should care much 
about degenerate reordering cases.  I'm not even sure we should bother 
spending much energy in our evaluation tests making it happen at all 
(which isn't to say that the algorithm authors shouldn't consider it and 
if they feel it would affect them, test it or discuss it - plus they 
will see a small amount of it on real networks).


-- 
Randell Jesup -- rjesup a t mozilla d o t com