Re: [tsvwg] The List (of application-layer desired features)

On Wed, Sep 4, 2013 at 10:12 AM, Joe Touch <touch@isi.edu> wrote:
>
>
> On 9/4/2013 8:21 AM, Yuchung Cheng wrote:
> ...
>
>> Here is a problem I don't think there is a good practical solution:
>> multi-flows. Currently browser uses some heuristics to determine
>> number of parallel connections to trade-off latency and congestion,
>> because the transport does not provide a good service for that.
>
>
> Transports don't read minds.
>
>
>> HTTP/2 reduces one factor by limiting #connections per host to 1 but
>> that's
>> not enough.
>
>
> That's not an appropriate solution - and it's the sort of "mis-use" I was
> referring to. It only serves to push muxing up the stack.
The transport(s) that can keep muxing down the stack don't always run
on the Internet. This is what Roberto's argument is about.

>
>
>> IMHO the transport (tcp, sctp, quic, or anything you
>> prefer) should just take connection priorities dynamically from the
>> app, and schedule connections more intelligently at the receiver. It's
>> not the app's job or can he do a good job at higher layer.
>>
>> There is an old work called congestion manager but it's not useful b/c
>> it's sender based.
>
>
> RFC2140 avoids sets of connections from both getting more than their
> steady-state fair-share, and reduces the amount they step on each other.
> It's already deployed, but might benefit from some app-layer hints.
>
> IMO, this isn't a "transport" problem, though - it's more like a missing
> coordination layer (whether implemented with headers and state or just an
> API to the OS).
Any name is fine with me as long as the solution works.

>
> Joe

Received on Wednesday, 4 September 2013 17:52:50 UTC