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

I suspect that Yuchung meant 'widely deployed and available', when he says
'always'. That should certainly be true for TCP.

Personally, I think that UDP encapsulated stuff has a fighting chance.
Deployment is a matter of addressing any new features and protocol
technical issues of the current non end-to-end internet, and sticking a
binary on participating machines.
This is a reasonably bounded problem, thus, has a fighting chance.

I suspect that, without kernel support for interpacket delay measurement
and interpacket gap enforcement, any such protocols will do worse than they
would with such support, but hopefully that is about enhancement and not
required to make something new work well.

-=R


On Wed, Sep 4, 2013 at 11:40 AM, Michael Tuexen <
Michael.Tuexen@lurchi.franken.de> wrote:

>
> 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
> >
> >
>
>