[Tmrg] Now, where were we...?

lachlan.andrew at gmail.com (Lachlan Andrew) Thu, 26 November 2009 00:09 UTC

From: "lachlan.andrew at gmail.com"
Date: Thu, 26 Nov 2009 11:09:50 +1100
Subject: [Tmrg] Now, where were we...?
In-Reply-To: <8A2358A2-7652-4820-B721-0755695D688F@ifi.uio.no>
References: <BE0E1358-7C27-46A8-AF1E-D8D7CC834A52@ifi.uio.no> <4B05A502.4050402@gmx.at> <1e41a3230911241017p26af6480sd8b4ff358e2363ef@mail.gmail.com> <aa7d2c6d0911241416q5ca1315br4f66da0b77e304c3@mail.gmail.com> <8A2358A2-7652-4820-B721-0755695D688F@ifi.uio.no>
Message-ID: <aa7d2c6d0911251609o3d3f8db4n825c16270960408@mail.gmail.com>

2009/11/25 Michael Welzl <michawe at ifi.uio.no>:
>
>> 2009/11/25 John Heffner <johnwheffner at gmail.com>:
>>> Another issue with delay as a signal is that, absent a means to
>>> measure one-way delay, it measures the forward and reverse paths
>>> together, whereas loss will be from only the forward path.
>
> how this is worse, in this aspect, than loss.
>
> Well, there is a subtle difference in how TCP does it; TCP
> is somewhat ignorant to occasional, isolated loss of
> ACKs, i.e. traffic on the backward path. But that's how
> the protocol operates, it's not an inherent feature of
> the metric "loss".

Perhaps John's point is that it is easier to distinguish between loss
on the forward path and that on the reverse path,  than to distinguish
delay on the the two separately.  As you point out, what we  do  with
that extra information is a different issue.  We don't have to do what
Tahoe++ does, but he is right that we have greater flexibility.

The question for the TMRG is how we should model/measure/benchmark the
behaviour of algorithms using delay.  Fun as it would be, we're not
chartered to invent congestion control methods.

I think it means that our (somewhat dormant) test suite should clearly
report the performance of flows in each direction when there is
asymmetric congestion, both because of asymmetric load and because of
asymmetric capacity.

Cheers,
Lachlan

-- 
Lachlan Andrew  Centre for Advanced Internet Architectures (CAIA)
Swinburne University of Technology, Melbourne, Australia
<http://caia.swin.edu.au/cv/landrew> <http://netlab.caltech.edu/lachlan>
Ph +61 3 9214 4837