W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2013

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

From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
Date: Wed, 4 Sep 2013 20:40:38 +0200
Cc: Joe Touch <touch@isi.edu>, Roberto Peon <grmocg@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>, tsvwg <tsvwg@ietf.org>
Message-Id: <FA8C422A-A723-430C-8208-DAF2F776F500@lurchi.franken.de>
To: Yuchung Cheng <ycheng@google.com>

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:15 UTC