Subject: [conex] Comments on use cases doc

From: <[email-masked]>
Date: Wed, 30 Mar 2011 12:32:40 +0100

http://tools.ietf.org/html/draft-ietf-conex-concepts-uses-01
I think the use case doc could be improved. I found it quite hard to see the ‘route’ through the set of use cases:
5.1.  ConEx as a basis for traffic management  . . . . . . . . . 10
     5.2.  ConEx to incentivise scavenger transports  . . . . . . . . 11
     5.3.  Accounting for Congestion Volume . . . . . . . . . . . . . 12
     5.4.  ConEx as a form of differential QoS  . . . . . . . . . . . 12
     5.5.  Partial vs. Full Deployment  . . . . . . . . . . . . . . . 13

Doesn’t “traffic management” include 2, 3 & 4? Is “partial vs full deployment” really a use case?

I wonder if it would be worth distinguishing use cases on the timescale at which they use conex information (I’m thinking back to the Technical Plenary presentation (from Johari?), this talked about different timescales: milliseconds-seconds; hours-days; months-years [if i remember right]):-

·         Fast timescale: Operator limits the rate each user can generate conex marks. It enables enduser controlled qos and thereby encourages ledbat-style apps

·         Medium timescale: operator limits the congestion volume each user generates; this might encourage users to shift some of their traffic to a different time of day (back-ups in off-peak times). By an ISP monitoring the conex marks from several downstream providers, the ISP might be better able to select between them or include a conex-based parameter in its SLA?

·         Long timescales: this might help an operator upgrade where congestion is high(?)

(This is supposed to be a way of structuring and presenting use cases; if an actual example has been rejected earlier as a bad one, please substitute something else)

I think it would be better to present the use cases and separately discuss how each compares with how you might achieve something similar /inferior today. For instance, comparing the first one above (operator limits the rate each user can generate conex marks) with what might be done today (fair sharing and similar things)

I think discussion of partial deployment would be better as a separate section that referred back explicitly to one or more of the use cases already discussed and explained how they work (or don’t) in a partial deployment scenario. The current text in the section doesn’t really talk about the use cases (instead it is some discussion about deployment considerations). Specifically, our charter says “However, the CONEX WG will initially focus on one use case, where the end hosts and the network that contains the destination end host are CONEX-enabled but other networks need not be.” – so some discussion should concentrate on this scenario.

Couple of comments on terminology:
In “congestion-rate” definition you use the term “instantaneous congestion” which is not defined (it seems to mean something much more specific than the “congestion” definition)
“ingress” and “egress” definitions do not fit with their later use (when they are specific for a network)

Best wishes
phil

---

From: "Toby Moncaster" <[email-masked]>
Date: Wed, 30 Mar 2011 14:07:21 +0100

Hi Phil,

Thanks for your comments. I had already started to wonder about imposing
some structure like the one you mention. In particular I feel it may be a
way to better integrate Dave's long timescales section into the rest of the
document.

inline

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of [email-masked]
> Sent: 30 March 2011 12:33
> To: [email-masked]
> Subject: [conex] Comments on use cases doc
> 
> I think the use case doc could be improved. I found it quite hard to
> see the 'route' through the set of use cases:
> Doesn't "traffic management" include 2, 3 & 4? Is "partial vs full
> deployment" really a use case?
> 
> I wonder if it would be worth distinguishing use cases on the timescale
> at which they use conex information (I'm thinking back to the Technical
> Plenary presentation (from Johari?), this talked about different
> timescales: milliseconds-seconds; hours-days; months-years [if i
> remember right]):-
> 
> .         Fast timescale: Operator limits the rate each user can
> generate conex marks. It enables enduser controlled qos and thereby
> encourages ledbat-style apps
> 
> .         Medium timescale: operator limits the congestion volume each
> user generates; this might encourage users to shift some of their
> traffic to a different time of day (back-ups in off-peak times). By an
> ISP monitoring the conex marks from several downstream providers, the
> ISP might be better able to select between them or include a conex-
> based parameter in its SLA?
> 
> .         Long timescales: this might help an operator upgrade where
> congestion is high(?)

Can also include some stuff from Dave's section

> 
> (This is supposed to be a way of structuring and presenting use cases;
> if an actual example has been rejected earlier as a bad one, please
> substitute something else)
> 
> I think it would be better to present the use cases and separately
> discuss how each compares with how you might achieve something similar
> /inferior today. For instance, comparing the first one above (operator
> limits the rate each user can generate conex marks) with what might be
> done today (fair sharing and similar things)

We certainly need to make it clearer why ConEx is better than today's
technology. 

> 
> I think discussion of partial deployment would be better as a separate
> section that referred back explicitly to one or more of the use cases
> already discussed and explained how they work (or don't) in a partial
> deployment scenario. 
O
This is already on the todo list.

>The current text in the section doesn't really
> talk about the use cases (instead it is some discussion about
> deployment considerations). Specifically, our charter says "However,
> the CONEX WG will initially focus on one use case, where the end hosts
> and the network that contains the destination end host are CONEX-
> enabled but other networks need not be." - so some discussion should
> concentrate on this scenario.

I am starting to think we need to narrow our focus within this document. It
is clear that by trying to include too wide a range of use cases we are
actually risking alienating some people. Clearly we need to show that ConEx
is applicable more widely than the narrow scope of the charter, but we
equally need to show that within that narrow scope ConEx has some
applicability (otherwise we'll never answer our critics who ask what is the
point of ConEx).

> In "congestion-rate" definition you use the term "instantaneous
> congestion" which is not defined (it seems to mean something much more
> specific than the "congestion" definition)

Thanks. I'll check and either improve the definition or add one for
instantaneous congestion.

> "ingress" and "egress" definitions do not fit with their later use
> (when they are specific for a network)

OK, I'll check and clarify either the definition or the usage. The chances
are that the definition got left behind when we removed the section on
mechanism from an earlier draft...

Toby

> 
> Best wishes
> phil
> _______________________________________________
> conex mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/conex