- From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
- Date: Wed, 4 Sep 2013 20:40:38 +0200
- To: Yuchung Cheng <ycheng@google.com>
- Cc: Joe Touch <touch@isi.edu>, Roberto Peon <grmocg@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>, tsvwg <tsvwg@ietf.org>
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