[R-C] Why not TFRC?

[Randell Jesup]

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.

> 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).

-- 
Randell Jesup
randell-ietf at jesup.org