Re: [conex] Potentially interesting ConEx problem

Is this problem not mostly negated at the application layer in most video clients? They dynamically adjust to the realtime end to end bandwidth on an end user by end user basis. 

For a metro or backbone topology failure this method once again adapts per end point affected, over any aggregate path these clients are running over.

Moreover the expression of congestion by an ISP to an off net provider is not really an attribute you would like to advertise and used to berate the SP with.

QoS is your friend here if you wish to actually protect valued traffic, rather the bringing whole bunches of users to the lowest common bandwidth for an app.

Andrew

On 5 Mar 2013, at 17:36, "Matt Mathis" <mattmathis@google.com> wrote:

> Bob, I do know how to do it from the ISP's vantage point.
> 
> It is a bit harder from the content provider's vantage point.   A
> large content provider might, for example, want to be able to
> distinguish between appropriately filling subscriber links and
> aggravating some capacity failure elsewhere along the path.
> Traditional serving optimizations actually make this problem far
> worse: serving from as many places as possible, as close to the users
> as possible makes the system even more brittle to ISP failures.
> 
> There is not an easy way to do this today.  There are inference
> signals (e.g. correlated losses across flows) but the signals are
> expensive and slow.
> 
> Thanks,
> --MM--
> The best way to predict the future is to create it.  - Alan Kay
> 
> Privacy matters!  We know from recent events that people are using our
> services to speak in defiance of unjust governments.   We treat
> privacy and security as matters of life and death, because for some
> users, they are.
> 
> 
> On Tue, Mar 5, 2013 at 1:53 AM, Bob Briscoe <bob.briscoe@bt.com> wrote:
>> Matt,
>> 
>> The solution to the access link part of this problem is explained in:
>> <http://tools.ietf.org/html/draft-briscoe-conex-initial-deploy-03#section-4.1.1>
>> 
>> It can only distinguish access link congestion from shared congestion.
>> Distinguishing home network congestion is harder, but possible with a tunnel
>> to the home router, which already exists in some DSL arrangements (e.g. in
>> BT we use a tunnel for services that share a line).
>> 
>> 
>> Bob
>> 
>> 
>> At 22:18 04/03/2013, Matt Mathis wrote:
>>> 
>>> I have an interesting problem that I wish ConEx could solve, but I
>>> don't see how.   I want to distinguish between congestion on the path
>>> between a server and a subscriber aggregation point (e.g. DSLAM etc)
>>> and congestion beyond the aggregation point (e.g. the access links
>>> themselves, or the user's home network).
>>> 
>>> There are some ways to infer this, but as far as I can tell there is
>>> not a reasonable way to measure it directly.   This is a problem that
>>> we have touched on in the past, but I don't recall discussing any
>>> solutions.
>>> 
>>> Thanks,
>>> --MM--
>>> The best way to predict the future is to create it.  - Alan Kay
>>> 
>>> Privacy matters!  We know from recent events that people are using our
>>> services to speak in defiance of unjust governments.   We treat
>>> privacy and security as matters of life and death, because for some
>>> users, they are.
>> 
>> 
>> ________________________________________________________________
>> Bob Briscoe,                                                  BT
> _______________________________________________
> conex mailing list
> conex@ietf.org
> https://www.ietf.org/mailman/listinfo/conex