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

[Stefan Holmer <[e-mail]>]

On Fri, May 2, 2014 at 11:49 AM, Randell Jesup <[e-mail]>wrote:

> On 4/30/2014 1:51 PM, Colin Perkins wrote:
>
>> On 30 Apr 2014, at 07:50, Zaheduzzaman Sarker <
>> [e-mail]> 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).


+1


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