[R-C] Why not TFRC?

[Piers O'Hanlon]

On 9 November 2011 05:48, Randell Jesup <randell-ietf at jesup.org> wrote:
> On 11/8/2011 6:41 PM, Piers O'Hanlon wrote:
>>
>> On 8 November 2011 22:46, Randell Jesup<randell-ietf at jesup.org>  wrote:
>>>
>>> Except we need to control delay, so we *can't* let it get to loss if
>>> there's
>>> any deep buffering.  There's also the question of "what is fair" if we
>>> replace 4 streams with one "combined" stream - it shouldn't have its
>>> share
>>> drop to 1/4 of what it was.
>>>
>> Sure though I guess we're probably in a lucky position if we're the
>> only flow on the link that might have control over whether there is
>> actually delay or not? I'd have thought that a lot of links are going
>> to have share with at least the odd TCP flow that has already brought
>> the delay up.
>
> The problems will come from either pageloads or other TCP traffic (email
> fetch/IMAP check, etc) from the same machine, or either established flows or
> pageload bursts on other devices in the same home or same WiFi link.
>
Yes that's what I was thinking so I wonder how often it is that a
delay based algorithm has the chance to actually control the delay
much as the parallel TCP sessions will take up the slack. Even on
today's home networks there's at a least a couple of devices which may
be sharing the same link with longer lasting flows (e.g. iPlayer/Hulu
over TCP, downloads etc).

>> The fairness issues can be tricky - I guess there's lots of tricks
>> that have been played with trying to multiple streams to gain on
>> single streams. It depends how fair you want to be and on what terms.
>> Should we go Conex or just flow fair...?
>
> Witness the "2 connections" limit for HTTP.... and how both browsers and
> websites bend things (browsers by using more than 2 or pre-warming extra
> connections; websites by sharding their servers to encourage browsers to
> generate more connections at once).
>
Yeah and unfortunately the work to reduce HTTP latency can have the
opposite effect on realtime flows - when things like Initial Window=10
is used, especially in conjunction with multiple flows. Though
potentially with delayed based bulk transfer it may be ok - I'm
curious whether anyone has seen any benefits in this area when
competing with Microsoft's Compound TCP (though as you pointed out
with TFRC the delay aspect of CTCP may also not be about reducing
latency).


Piers.

> --
> Randell Jesup
> randell-ietf at jesup.org
> _______________________________________________
> Rtp-congestion mailing list
> Rtp-congestion at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtp-congestion
>