Subject: [conex] Comments on the two draft-moncaster-conex-*

From: Jukka Manner <[email-masked]>
Date: Thu, 29 Jul 2010 17:09:44 +0200

Hi,

I went through the two draft-moncaster documents, use cases and problem 
statement. They are mostly readable and relatively easy to follow. Some 
parts really need more explanation, or at least some thought (probably 
just the latter).

I have two proposals:

1. The two drafts have a lot in common and a reader checking both drafts 
will encounter a lot of repetition. I would suggest to consider if the 
documents could be merged as one.

2. It is not very obvious how would the network in practice find and 
treat two users, where one is a heavy user and the other a small user 
(or users). Could you add some text on how the conex scheme would work, 
show some concrete example with network congestion, created load and the 
network response. I know this info is there but it would benefit from a 
concrete example(s) with numbers.

Hope this helps,
Jukka

---

From: "Toby Moncaster" <[email-masked]>
Date: Thu, 29 Jul 2010 18:17:01 +0100

Hi Jukka,

Thanks for  the comments... Some responses inline

Toby

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Jukka Manner
> Sent: 29 July 2010 16:10
> To: [email-masked]
> Subject: [conex] Comments on the two draft-moncaster-conex-*
> 
> Hi,
> 

The Problem statement draft was written as part of the motivations for
setting up this working group. It has now served its purpose and the authors
are probably going to allow it to expire. The idea is that the Use Cases
document should pick up some of the key motivations from the problem
statement and is, in effect, the next step

> concrete example(s) with numbers.

Reliably identifying different users is always going to be an issue in the
Internet. In the absence of source-address spoofing you can identify a
source-destination pair and use that. By adding up all the congestion-volume
you see for each id at a given point you can identify the "heaviest" users.
At the border of a network, the operator can use ConEx to see how much
congestion is being caused in its network by each source (if it trusts
source addresses) or can use other heuristics to identify which user is
"heavy" and which isn't...

{individual reply as 1 of 4 authors} I might consider having a simple
numerical example, probably as an appendix to the use cases. 

> 
> Hope this helps,
> Jukka
> _______________________________________________
> conex mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/conex

---

From: "Mcdysan, David E" <[email-masked]>
Date: Thu, 29 Jul 2010 14:22:46 -0400

Hi,

A few responses in line.

Dave 

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Toby Moncaster
> Sent: Thursday, July 29, 2010 1:17 PM
> To: 'Jukka Manner'; [email-masked]
> Subject: Re: [conex] Comments on the two draft-moncaster-conex-*
> 
> Hi Jukka,
> 
> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> > Of Jukka Manner
> > Sent: 29 July 2010 16:10
> > To: [email-masked]
> > I went through the two draft-moncaster documents, use cases and 
> > problem statement. They are mostly readable and relatively easy to 
> > follow. Some parts really need more explanation, or at least some 
> > thought (probably just the latter).
> > 
> > I have two proposals:
> > 
> > 1. The two drafts have a lot in common and a reader checking both 
> > drafts will encounter a lot of repetition. I would suggest 
> to consider 
> > if the documents could be merged as one.
> 
> The Problem statement draft was written as part of the 
> motivations for setting up this working group. It has now 
> served its purpose and the authors are probably going to 
> allow it to expire. The idea is that the Use Cases document 
> should pick up some of the key motivations from the problem 

Makes sense to me. I just sent comments on the general use case vs
mechanism comment I posted earlier this week as requested by the chair
for your consideration.

> > (or users). Could you add some text on how the conex scheme would 
> > work, show some concrete example with network congestion, 
> created load 
> > and the network response. I know this info is there but it would 
> > benefit from a concrete example(s) with numbers.
> 
> Reliably identifying different users is always going to be an 
> issue in the Internet. In the absence of source-address 
> spoofing you can identify a source-destination pair and use 
> that. By adding up all the congestion-volume you see for each 
> id at a given point you can identify the "heaviest" users.
> At the border of a network, the operator can use ConEx to see 
> how much congestion is being caused in its network by each 
> source (if it trusts source addresses) or can use other 
> heuristics to identify which user is "heavy" and which isn't...
> 
> {individual reply as 1 of 4 authors} I might consider having 
> a simple numerical example, probably as an appendix to the use cases. 
> 

I agree that a use case of heavy vs small user is an important use case.
Possibly the example from section 8.4 of the use case draft could be
amended with this concept and expand the tragedy of the commons example
to have shepherds with flocks of different sizes.

I had this use case in mind at the mike at the plenary from Frank
Varian, a version of which might be a start for the text you propose in
an appendix:

In many networks, 20% are heavy users generate 80% of the traffic. This
means that a heavy user generates 16 times as much traffic as a small
user. However, in a bandwidth tier priced network, heavy and small users
may in fact pay nearly the same price. On average during periods of peak
use, the heavy user sends at near the bandwidth tier value while small
users send in an intermittent manner. The (access) network is engineered
at the peak capacity of all these users, and when it is congested, the
heavy users are creating 16x the congestion of small users. Long-term
(e.g., monthly) usage volume based pricing helps address this inequity,
but; is complex for users to understand, and does not address the
situation where heavy users send at a high rate, but only for a fraction
of the usage measurement interval (e.g., a month). What is needed in the
use case is a more equitable means for a service provider to more
equitably assign allocation of costs to the heavy and small users.