Re: [conex] [httpstreaming] [dispatch] Q-HTTP

Cheers
Kevin Mason
> -----Original Message-----
> From: Toby Moncaster [mailto:toby@moncaster.com]
> Sent: Tuesday, 23 November 2010 3:50 a.m.
> To: 'Mikael Abrahamsson'; Kevin Mason
> Cc: conex@ietf.org
> Subject: RE: [conex] [httpstreaming] [dispatch] Q-HTTP
> 
> 
> 
> > -----Original Message-----
> > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf
> > Of Mikael Abrahamsson
> > Sent: 22 November 2010 06:19
> > To: Kevin Mason
> > Cc: conex@ietf.org
> > Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP
> >
> > On Mon, 22 Nov 2010, Kevin Mason wrote:
> >
> > > [Kevin Mason] TCP, LEDBAT, the proposed Q-HTTP among others are
> > > primarily tools for users so I don't see any lack of "tools" for
> > users.
> > > CONEX I understand is trying to provide some of that visibility to
> > > providers because zero congestion is not achievable at any realistic
> > > price unless all sources directly connected to access lines (i.e.
> > there
> > > is no core !).
> >
> > At IETF75 I proposed in multiple WGs (and at the general session one
> > evening) to have some work done to give the user insight into what TCP
> > (and other protocols) is doing. I still haven't seen any takers or even
> > someone saying this is a way forward that they think is worthwile
> > spending
> > time on. Zero.
> 
> Or perhaps they think that is a job for OS writers, not the IETF? There
> are
> limits to what the IETF should take on else we will spread ourselves
> rather
> too thin...
> 
> 
> > So I would like to say that using TCP as an example of "tool" for a
> > user
> > to see what is going "on", is not something I agree on today. Q-HTTP
> > might
> > do it if I understand it correctly, but I don't like that it actually
> > introduces testing traffic, when instead my strong opinion is that one
> > should not introduce testing traffic, one should instead look at the
> > real
> > traffic and what is going on there. TCP has lots of tools to help
> > itself
> > (timestamping, noticing single packet loss etc), but there is no way to
> > expose this to the general user. I can fire up wireshark and spend
> > minutes/hours trying to figure out what is going on, but I've been
> > doing
> > packet networking for 15+ years and know my way around that tool.
> >
> > I don't know what tools LEDBAT has to inform the user, but I guess
> > since
> > it's "background" the user can see the transfer speed to see what extra
> > bandwidth is available, and when it's very low, the network is
> > obviously
> > full.
[Kevin Mason] My definition of "tool" is perhaps wider that yours, in that these protocols already expose end to end path information to end user devices. The user's application is acting on the user's behalf, so the extent to which path information derived from the transport protocol is literally conveyed to the "human user", rather than acted on by the application in an attempt to achieve the experience or outcome preferences set by the human user, are from a network behaviour perspective synonymous.

No equivalent information is currently exposed to the network to enable a service provider to observe the current impact of user behaviour to craft and manage suitable incentives and rewards for mutually beneficial behaviours.

> 
> To my mind it is NOT sensible to show users what is happening. Bluntly,
> 99%
> of people couldn't care less how the Internet works, what their PC is
> doing
> when they start a Skype video call, etc, any more than they want to know
> what their car's engine management system does when they press the gas
> pedal.
> 
> What things like LEDBAT are trying to do is translate the user's behaviour
> (we want a file, so we tell our PC to find it and download it) into
> sensible
> actions (user is also doing something interactive and if the file transfer
> grabs all their bandwidth suddenly their interactive session dies, so we
> slow the transfer down until the interactive session goes away).
> 
> I do believe there is room for improvement (perhaps an app that allows the
> user to say, actually this transfer is quite important as I want to watch
> this film tonight (said film being copyright free or paid for of course ;)
> 
> I am not convinced the IETF should be going into that much detail
> though...
> 
> Toby
> 
> >
> > --
> > Mikael Abrahamsson    email: swmike@swm.pp.se
> > _______________________________________________
> > conex mailing list
> > conex@ietf.org
> > https://www.ietf.org/mailman/listinfo/conex