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

On Sep 4, 2013, at 7:52 PM, Yuchung Cheng <ycheng@google.com> wrote:

> 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.
I think "running always" is hard... Not sure if TCP does.
So what about UDP encapsulated stuff like SCTP/UDP?

Best regards
Michael
> 
>> 
>> 
>>> 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 18:41:04 UTC