Re: [conex] Potentially interesting ConEx problem

[Bob Briscoe <[e-mail]>]

Andrew,

Going back in the thread to your point...


At 18:13 05/03/2013, Andrew McLachlan (amclachl) wrote:
>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.

Yes, by driving load until they detect losses. That's just normal 
regular congestion avoidance & control. So far, that's nothing to do 
with ConEx, which doesn't propose to change what the network tells 
hosts. Rather, it's about hosts telling the network what e2e 
congestion they have detected.

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

Yes. Again, nothing new here.

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

A link cannot not signal congestion (double negative intended) if 
hosts are overloading it with traffic, even briefly. It has to 
discard as much traffic as it has to discard. It's only choice is in 
whether it does that randomly (ie proportionate to instantaneous 
load) or focused (leading into your QoS point next).

This still isn't related to ConEx, which is about the sender 
signalling the e2e congestion it detects back into the network, in an 
e2e field, which hosts can integrity-protect against networks 
altering it if they choose. ConEx is not about whether the network 
signals congestion (because it has no choice over that).

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

ConEx is about intra-class protection of traffic. The operator can 
use QoS classes (or not), and it could manage traffic within a class 
using ConEx (or not).

ConEx will be useful for focusing policing on particularly heavy 
sources within a class. QoS (Diffserv) focuses discards on all lower 
class traffic indiscriminately. The two could work together, so 
during overload QOS protects valued traffic and even in the lower 
classes ConEx will protect most traffic, while only shedding traffic 
from the heaviest customer(s) in the lower class.

I believe you are dividing traffic up into valued (premium) and not, 
but customers also value and pay for this so-called 'not valued' 
traffic. And operators don't only care about premium traffic - they 
know they can't afford to lose custom for either service type.


Matt's question was about how the network can infer whether 
congestion is shared or self-congestion (policing the major 
contributers would help in the former, but not the latter).



Bob



>Andrew
>
>
>
>
>
>On 5 Mar 2013, at 17:36, "Matt Mathis" <[e-mail]> 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 <[e-mail]> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/conex

________________________________________________________________
Bob Briscoe,                                                  BT