[Iccrg] Answer to MulTFRC reviews

[Michael Welzl]

Hi,

Sorry for the delay...


On Jan 22, 2010, at 1:33 AM, Lachlan Andrew wrote:

> Greetings Michael / all,
>
> A lot of our disagreement relates to the source of loss.  If the only
> loss is self-induced loss by long-lived flows, then I agree with many
> of your statements.  However loss is often caused by short-lived flows
> slow-starting until they force a loss.  I'll explain how that matters
> in a couple of the cases below.

Okay; I also think that some of our disagreement...


>
> 2010/1/22 Michael Welzl <michawe at ifi.uio.no>:
>> On Jan 21, 2010, at 1:05 AM, Lachlan Andrew wrote:
>>> 2010/1/20 Michael Welzl <michawe at ifi.uio.no>:
>
>>> My point was that standard TCP is   sufficiently   aggressive in a  
>>> LAN
>>> environment.
>>
>> Not necessarily - this depends on the buffer size:
>
> If the BDP is small, the only way for TCP not to get a high throughput
> (after slow start) is for the loss rate to be quite high.  If the
> buffer isn't enough to prevent loss of the order of one packet in 100,
> then making TCP "the same but more aggressive" just makes life worse
> for loss-sensitive applications.

Well - if there is only one flow on the bottleneck (consider
the not so unusual situation of a user watching a video over
the Internet, with the bottleneck being his/her home access
connection), and the buffer is very small, then the average
utilization of this link declines with standard TCP, with a
lower end of only 75%.

More generally, this is true whenever the buffer is very
small compared to the BDP, leading to my argument in
favor of a mechanism that can reach a higher percentage.


> If the buffer is sufficiently large, then the limitation on TCP is
> from bursty cross-traffic.  Since it only takes TCP a few RTTs (a few
> ms on a LAN) to recover a BDP-sized window, I'd argue that TCP is
> "sufficiently aggressive" to handle flows which start occasionally.

I agree. Note, however, that we are
1) not proposing a TCP replacement
2) not proposing a mechanism that is under all circumstances
more aggressive than TCP as its only benefit. MulTFRC covers
a wide range of values for N (the number of emulated flows),
including values between 0 and 1, i.e. it can let its users reduce
the aggression below that of TCP. I think that this can be useful
too, e.g. if I'm happy enough with the video quality even if N < 1
and want to download something fast at the same time.


>> How do you define "too aggressive"?
>
> Nothing precise.  Perhaps "transmitting so many packets into the
> network that the incremental damage we do to other traffic is greater
> than the incremental benefit to ourselves".  In this case, we get no
> additional benefit from keeping the average (not peak) buffer
> occupancy high, but we cause problems for others.

...the problem being that "damage" and "benefit" are extremely vague
terms. That was my point: it very much depends on what users want.
If I'm happy with voice quality while a video is transmitted with
MulTFRC with N=6 in the background, then that's fine. Anyhow my
main argument is that the ability to change N (as opposed to the fixed  
N=1
value that standard TFRC gives you) is useful.


>> It causes delay, by letting the queue overflow, which, as you
>> rightly say, is true for any loss-based algorithm.
>
> Loss only requires the peak buffer occupancy to be high -- not the  
> average.

Yes - and so...?


>> I would argue that, while this is an interesting study, trying
>> to optimize a mechanism for it is to optimize it for a very
>> poorly tuned special circumstances
>
> You're right that we shouldn't optimise for it, but we should consider
> it.  It is just an example of a case when making TCP more aggressive
> is not appropriate.

I can easily take a case
(fig. 3 in L. Stewart, G. Armitage, A. Huebner, "Collateral Damage:
The Impact of Optimised TCP Variants On Real-time Traffic Latency
in Consumer Broadband Environments", IFIP/TC6 NETWORKING 2009,
Aachen, Germany, 11-15 May 2009.)
out of Lawrence's investigation that you mentioned to argue
against what you say here: HTCP appears to sometimes
cause less (in other cases, at most as much) extra delay for
other flows than standard TCP does. Yet, it is *more* aggressive.

So, we would first have to investigate what the delay impact of
MulTFRC really is before making a judgement like that. I'd agree
that this is a useful investigation to do, but I'd also argue against
making this a reason to accept or not accept publication of MulTFRC
as an Experimental RFC, or even to make a general recommendation
about the setting of N, because of what we both agree on above:
that the case is worth considering, but not optimising for.


>> where the only real
>> solution is to throw all non-delay-based schemes away.
>
> As an aside, there's a big difference between "delay-based schemes"
> and schemes which detect persistently high queueing delay.  I strongly
> believe that new-generation congestion control should try to use all
> available information, including both loss and delay.  Occasional
> peaks in delay may be spurious, and so purely delay-based schemes are
> problematic.  However, if the delay is consistently high and reducing
> our window does not reduce our throughput, then I think we have no
> excuse not to reduce our window.

I tend to agree with your view, but would not want to reject,
say, CUBIC (heh, or MulTFRC!  ;-)  )  on this basis. Also note
that not everyone agrees that delay (or fluctuations thereof)
is a reliable enough source of information, cf. the discussion
that we had about this in TMRG.


>> Indeed, the buffer size is the problem, and I don't see how
>> this fact changes by saying "if the BDP were higher then the
>> size of the buffer would be fine" - because it just isn't higher,
>> and if it was, the problem would disappear, both with
>> MulTFRC and with all other loss-based mechanisms.
>
> The BDP *is* higher on some paths than on others.  The buffer at a
> link is always going to be too big for some paths and too small for
> others.  We don't need the case to be as extreme as current ADSL links
> for that to remain true.

Okay, true - but my answer related to your ADSL example which
we have discussed above, and the larger the BDP, the less
of a problem this becomes (because the buffer would then
have to be even larger to cause the problem that we're talking
about). In other words, the case doesn't get more interesting
if we look at larger BDPs - it shifts in favor of MulTFRC with
a large N  :-)


>>>> upper limit, which we recommend to have.
>>>
>>> That limits the scalability.  It may buy us an extra generation of
>>> Ethernet (increase aggressiveness by a factor of 10 to match going
>>> from GbE to 10GbE), but doesn't address the inherent scalability
>>> problem.
>>
>> I don't get this, most probably it's a misunderstanding.
>> A limit of, e.g., N=6 emulated flows, will always give you
>> at least 95% link utilization or more, irrespective of the BDP.
>
> We get 95% utilisation if the only loss is self-induced.  However, if

Sorry, yes - I wrote "at least", meaning "irrespective of the
queue length". Of course, that is only the "I am the only one"
(i.e. self-induced loss) case.


> the BDP is large and there a loss because another flow slow-started
> and then disappeared, then it will take a long time to recover.

> That was always the fundamental problem with Reno on high BDP links,
> wasn't it?  Without cross traffic, even small buffers give 75%
> utilisation for arbitrarily large BDPs under Reno, but it takes hours
> to recover from a few seconds' cross traffic on some hop.

Agreed. Being more aggressive, more flows (and, similarly,
MulTFRC with N>1 ) recover faster, but a fixed value of N
may be too much for some links (case 1) and not enough for
other (case 2).

Case 1: I don't believe this with N=6 because, pragmatically,
from practical experience that I and many others have,
6 TCP flows have worked well even under very poor conditions.
I have personally 6 and more parallel flows to download files
since the early 90's, and the number of downloads as well
as different network conditions that I tried over the years
is surely enough to give a statistically sound result, even
without a diagram showing it   :-)

Case 2: This is very obvious, I believe, and it's also why we're
not in the least suggesting MulTFRC as a new TCP variant - for
the same reason why noone has ever written a paper suggesting
MulTCP with N > 1 instead of e.g. CUBIC, HTCP etc I suppose  :-)


>>> Of course, for an experimental RFC it need not be the very best
>>> solution, but receiving that stamp is a strong endorsement.  I'd be
>>> more in favour of a rate-based version of one of the new-generation
>>> algorithms already before the ICCRG (C-TCP, CUBIC or H-TCP) or  
>>> LEDBAT.
>>> Once simulation/test-bed studies have shown which of the four  
>>> options
>>> seems most promising for "new TFRC", we can set the best one loose  
>>> on
>>> the internet.
>>
>> Now that really makes no sense to me, as MulTFRC is
>> not a TCP variant, and by no means meant to be one.
>> Being slowly reactive, yet having a smooth sending rate
>> (which most TCP applications wouldn't care about),
>> it is just not designed to replace Reno, C-TCP, CUBIC,
>> H-TCP etc. You're comparing apples with oranges here.
>
> I agree that MulTFRC is not a TCP variant, but it is a congestion
> control algorithm.  I though it's aim was to be a rate-based companion
> to MulTCP.

I greatly prefer to see it as an extension of TFRC in the
spirit of MulTCP. That is a major difference: MulTCP is
known not to work well and hasn't been studied as
deeply as TFRC. It is also not designed for multimedia
applications (which want a smooth rate), as TFRC is.


> My argument is that MulTCP has not yet (to my knowledge) been assessed
> by the ICCRG, but that the other congestion control algorithms that I
> mentioned have.  If we are going to let a new rate-based congestion
> control algorithm loose, we SHOULD (not MUST) choose one based on a
> carefully-evaluated window-based algorithm in preference to a
> less-well evaluated one.  That is, the draft should make a case why
> rate-based "equivalents" of the approaches taken by CUBIC, C-TCP or
> H-TCP are not suitable.

No, because TFRC has been evaluated in depth, and MulTFRC is really
nothing but a minor variation of it. What we have done is to (quite
thoroughly, I would say) show that it can act like N TFRCs in parallel,
with a great range of possible values for N, including 0<N<1, while
retaining TFRC's original properties even better than multiple real
TFRCs do.


> I wasn't suggesting that we use the window-based algorithms themselves
> in DCCP.  I was suggesting that we do for them what you have done for
> MulTCP**, and then compare all of the results by simulation/testbed
> before taking the step of endorsing MulTFRC as experimental.

We have plenty of results showing the above, from simulations, and
real-life tests in a local testbed as well as across the Internet. Some
of these results are documented in our CCR paper, and many
more are in Dragana's thesis which we can shortly make available.


> The logic behind TFRC was that the rate-based and window-based flows
> should behave similarly in response to network conditions.  Given
> that, we should make next-generation rate-based flows behave similarly
> to next-generation window-based flows.  Why experiment with MulTFRC if
> MulTCP isn't going to be deployed?

Because MulTCP is 1) not working too well, and 2) rather pointless.
CUBIC et al do a better job than MulTCP at what MulTCP is aiming at,
which is not the same as what (Mul)TFRC is aiming at.


> **That is, we should say "given this pattern of loss, what would the
> window/RTT be?" and set the rate accordingly.

It is set accordingly, as shown in numerous results that Dragana
has produced, where "what would the window/RTT be" is
in fact translated into "what would the behavior of standard TCP be".
There's a ton of diagrams in her thesis with loss on the x-axis, and
various different loss patterns too.

Cheers,
Michael