Subject: Re: [conex] ConEx is not the only solution? conex-concepts-uses

From: "Toby Moncaster" <[email-masked]>
Date: Tue, 12 Jul 2011 10:35:27 +0100

John carefully said solutions serve the need. That's a bit different from saying they perfectly address the Conex use cases... basically there are businesses that think they've solved this. 

Sent from my HTC

----- Reply message -----
From: "Bob Briscoe" <[email-masked]>
Date: Tue, Jul 12, 2011 09:45
Subject: [conex] ConEx is not the only solution? conex-concepts-uses
To: "Toby Moncaster" <[email-masked]>, "John Leslie" <[email-masked]>
Cc: "ConEx IETF list" <[email-masked]>

Toby, John,

Which other solutions do any of the three main use cases?

One of Comcast's conclusions from having built fair share was that these were things they couldn't do today.

So if anything we should be saying the opposite - that nothing else does these things (and referring to Comcast).

This is also true for:
- 'preventing congestion collapse' (other than voluntary use of congestion control) and
- seeing how much congestion is in which operator's network.

Informing provisioning is the only one that can be done other ways (but without congestion-based traffic management congestion doesn't necessarily mean you can know you *should* upgrade capacity).

Bob

At 06:59 12/07/2011, Toby Moncaster wrote:
>I think john's right about why that sentence was in there. I >certainly have no attachment to it.
>
>I'll try and read through the new version in the next few days...
>
>Toby
>
>Sent from my HTC
>
>----- Reply message -----
>From: "John Leslie" <[email-masked]>
>Date: Tue, Jul 12, 2011 01:26
>Subject: [conex] ConEx is not the only solution? conex-concepts-uses
>To: "Bob Briscoe" <[email-masked]>
>Cc: "ConEx IETF list" <[email-masked]>
>
>
>Bob Briscoe <[email-masked]> wrote:
> >
> > John, Toby,
> >
> > In the introduction to the main ConEx use cases (inform traffic mgmt,
> > incentivise LEDBAT & intra-class user-controlled QoS), it current says:
> >         "In most cases ConEx is not the only solution to achieve these. "
> >
> > I'd like to delete this sentence, as I don't believe it's true in
> > these cases (unless one admits significantly inferior "solutions").
> > And it's a statement that is damning enough to get an activity stopped.
>
>   I feel no attachment to that sentence -- I'm guessing we were saying
>that other "more traditional" "solutions" would continue to be used
>(and in some cases, there exist actual solutions to the issue which _do_
>serve the need.)
>
> > As previous editors of conex-concepts-uses, was there some history
> > behind including that sentence that I've missed?
>
>   Toby is in a better position to say...
>
>--
>John Leslie <[email-masked]>

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 12 Jul 2011 17:29:26 +0100

Toby,

What I'm fishing for is examples of things that can do each use-case. 
I don't mean can do well, I mean can do at all.

Bob

At 10:35 12/07/2011, Toby Moncaster wrote:
>John carefully said solutions serve the need. That's a bit different 
>from saying they perfectly address the Conex use cases... basically 
>there are businesses that think they've solved this.
>
>Sent from my HTC
>
>One of Comcast's conclusions from having built fair share was that 
>these were things they couldn't do today.
>
>So if anything we should be saying the opposite - that nothing else 
>does these things (and referring to Comcast).
>
>This is also true for:
>Informing provisioning is the only one that can be done other ways 
>(but without congestion-based traffic management congestion doesn't 
>necessarily mean you can know you *should* upgrade capacity).
>
>
>Bob
>

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design