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.
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@jesup.org