On 9 November 2011 05:48, Randell Jesup <randell-ietf@jesup.org> wrote:
On 11/8/2011 6:41 PM, Piers O'Hanlon wrote:
On 8 November 2011 22:46, Randell Jesup<randell-ietf@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@jesup.org _______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion