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

On Sep 5, 2013, at 12:20 AM, William Chan (陈智昌) <willchan@chromium.org> wrote:

> On Wed, Sep 4, 2013 at 2:58 PM, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:
> On Sep 4, 2013, at 9:43 PM, Roberto Peon <grmocg@gmail.com> wrote:
> 
> > I suspect that Yuchung meant 'widely deployed and available', when he says 'always'. That should certainly be true for TCP.
> That is definitely true for TCP.
> However, why do you need an alternate solution to be "widely deployed". Can't it
> be deployed within the browser?
> 
> I think people are being too imprecise which leads to confusion. UDP is widely deployed. A UDP based solution can be deployed within the browser. TCP-AO is not widely deployed. It cannot be deployed within the browser.
Sure. Completely agreed. Thanks for the clarification.

Best regards
Michael
> 
> For me it makes sense to require "availability" and "having a sufficient level of connectivity". 
> >
> > 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.
> This sounds to me like a performance optimisation. I guess this might be one feature
> of a larger set of features which improve the overall performance. However, the
> connectivity must be there at all. My expectation is that anything running over
> UDP might not have the same level of connectivity, but it should be acceptable.
> 
> Best regards
> Michael
> >
> > -=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
> >>
> >>
> >
> >
> 
> 
>

Received on Wednesday, 4 September 2013 22:24:54 UTC