Subject: [conex] comments/suggestions on draft-ietf-conex-concepts-uses-01

From: Nandita Dukkipati <[email-masked]>
Date: Thu, 17 Mar 2011 00:28:25 -0700

On reading the latest draft, I have three high level comments roughly in the
following order of importance-

***
Statistical Multiplexing over different timescales.
This reads like a rambling story. I have read and re-read it, and I am still
left wondering -
* What is _the_ main point? How about starting the section by stating your
main point upfront as opposed leaving it to the reader to figure it out.
* Why and how is this use case distinct from that of traffic management
which already seems to have a broad scope? Is it really distinct?
* [minor] Why not make this use case a part of Sec. 5?

***
Partial versus full deployment.
Clearly, it belongs to this draft. But why is it a part of use cases? Looks
out of place to me.

***
Sec 4. Exposing congestion.
“We argue that congestion needs.... More specifically, a network needs to be
able to measure how much congestion any particular traffic expects to cause
between the monitoring point in the network and the destination
("rest-of-path congestion"). This would be a new capability.”

Could you add more clarity and explanation on why local congestion
information at any given node is not sufficient. Why does a node require
congestion information from a monitoring point to the destination to be able
to manage its own congestion? A succinct explanation and/or an example will
go a long way.

---

From: "Toby Moncaster" <[email-masked]>
Date: Thu, 17 Mar 2011 09:53:07 -0000

Hi Nandita,

Thanks for the comments. Just for the record can you confirm whether these
are comments as WG chair, or as an individual contributor?

Addressing your three points in order:

Statistical multiplexing. This is a new section and so there is clearly a
lot of work needed to tidy it up and possibly to rationalise where it fits
in the structure of the document. Hopefully Dave can answer what the main
point is... As I understand things, Dave's view is that the main difference
is the measure of activity ratio that he introduces. As he sees things, this
is a different congestion measure to that used in the abstract mechanism and
so stands apart from the other use cases...

****

Partial vs Full Deployment. This does need a bit of work. And you are right
that it has now ended up in a strange place within the document. I will move
it to its own section in -02

****

Exposing congestion. We are not arguing that a node needs this information
to perform local congestion management. But it does need this information if
it is going to be held to account for dumping large quantities of congestion
on a node further downstream. In other words it allows the NETWORK to make
better congestion management decisions and avoids any tragedy of the
commons. Economists like Bob talk about maximising social welfare. I just
think of it as making the whole network run more efficiently (which benefits
everyone).

You could make a bad analogy: At 8 in the morning everyone living in a city
looks out of their windows and sees that the road outside their house is
clear (no congestion). So lots of them decide to get in their cars and head
off to the mall. As soon as they reach the freeway there is utter gridlock -
the congestion wasn't where they were, it was further along the path and
they just made it much worse. In fact in such cases we do make use of
something that gives us knowledge of the congestion further along the path,
namely local traffic reports on the radio (or smartphone, satnav, etc). 

Toby

From: Nandita Dukkipati [mailto:[email-masked]] 
Sent: 17 March 2011 07:28
To: Toby Moncaster; John Leslie; Bob Briscoe; Woundy, Richard; Mcdysan,
David E
Cc: [email-masked]
Subject: comments/suggestions on draft-ietf-conex-concepts-uses-01

*** 

*** 

***

"We argue that congestion needs.... More specifically, a network needs to be
able to measure how much congestion any particular traffic expects to cause
between the monitoring point in the network and the destination
("rest-of-path congestion"). This would be a new capability."

---

From: "Toby Moncaster" <[email-masked]>
Date: Thu, 17 Mar 2011 09:55:18 -0000

Off-list response...

If this was a comment by her as chair it's a bit rich. It was the chairs
that wanted us to add some of Dave's wanderings into the document in the
first place wasn't it? I didn't like to say to her that I too couldn't quite
see what Dave's point was. I certainly can't see why he needs so many words
to (fail) to make it.

*** 

*** 

***

---

From: "Mcdysan, David E" <[email-masked]>
Date: Thu, 17 Mar 2011 08:25:52 -0400

Hi Nandita,

A few responses to your questions on the new section in line below prefixed by DM which were previously posted to the list that I believe (at least partially) address your comments.

I propose that the working group work toward how to organize/merge/move the new text better into the existing outline.

Thanks,

Dave

From: Nandita Dukkipati <[email-masked]<mailto:[email-masked]>>
Date: Thu, 17 Mar 2011 03:28:25 -0400
To: Toby Moncaster <[email-masked]<mailto:[email-masked]>>, John Leslie <[email-masked]<mailto:[email-masked]>>, Bob Briscoe <[email-masked]<mailto:[email-masked]>>, "Woundy, Richard" <[email-masked]<mailto:[email-masked]>>, David McDysan <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: comments/suggestions on draft-ietf-conex-concepts-uses-01

On reading the latest draft, I have three high level comments roughly in the following order of importance-

***
Statistical Multiplexing over different timescales.
This reads like a rambling story. I have read and re-read it, and I am still left wondering -
* What is _the_ main point? How about starting the section by stating your main point upfront as opposed leaving it to the reader to figure it out.

DM - From my 3/10/11 on the list

1) A few "heavy" users generate most of the traffic and service providers
want to better assign the cost (of provisioning an upgrade) for the time
when congestion is anticipated to occur. Existing mechanisms, flat rate,
bandwidth tier shapers, and usage tiers do not completely address the
service provider objective and/or are not popular with users.

2) In some service provider networks shapers are implemented to limit the
maximum bandwidth per user. Although overflow or marking in the shaper
queue appears as congestion to the receiver,  this "self-congestion"
differs from congestion of a shared resource since a remedy could be to
indicate to the user that changing the shaper rate (i.e., "go faster")
would alleviate "self-congestion."

* Why and how is this use case distinct from that of traffic management which already seems to have a broad scope? Is it really distinct?

DM - From my 3/11/11 post to the list

Editorially, this (section 5.1) could be a place to state the problem with an additional
reference to [Varian].

Editorially, bandwidth tier pricing could be added to section 3.1,
Existing approaches.

I am now thinking that editorially a separate section is not a good idea,
since the points can be merged into the existing outline, in at least the
places mentioned above.

I think adding that the use case needs to meet service provider economic
congestion needs as well as be acceptable to users is an important point
not in the current text. Traffic management (aka policing) may have the
problem that it may not be popular with user. There has already been
negative feedback on the list regarding policing (IMO, Traffic management
is a better term).

DM – the minutes recorded adding the agreement to add this as a new section. (A new subsection, and or merging thoughts with other use cases (e.g., as suggested above) is what I believe the wg needs to discuss.

***
Partial versus full deployment.
Clearly, it belongs to this draft. But why is it a part of use cases? Looks out of place to me.

***
Sec 4. Exposing congestion.
“We argue that congestion needs.... More specifically, a network needs to be able to measure how much congestion any particular traffic expects to cause between the monitoring point in the network and the destination ("rest-of-path congestion"). This would be a new capability.”

Could you add more clarity and explanation on why local congestion information at any given node is not sufficient. Why does a node require congestion information from a monitoring point to the destination to be able to manage its own congestion? A succinct explanation and/or an example will go a long way.

---

From: Nandita Dukkipati <[email-masked]>
Date: Sat, 19 Mar 2011 00:15:31 -0700

> are comments as WG chair, or as an individual contributor?

I should have made that clear in the first place - I am making my comments
as an individual contributor.

> point is... As I understand things, Dave’s view is that the main difference

Clearly, this section needs work to bring out the essence of the matter in a
succinct way. I don't quite get the main point of the section to offer any
meaningful help.

> it to its own section in -02

Sounds good to me.

****
> off to the mall. As soon as they reach the freeway there is utter gridlock –
> the congestion wasn’t where they were, it was further along the path and

That was actually a good explanation. It's worthwhile trying to frame what
you explained in a formal way with an example taken from the networking
context.

>
>
> Toby
>
>
>
> *From:* Nandita Dukkipati [mailto:[email-masked]]
> *Sent:* 17 March 2011 07:28
> *To:* Toby Moncaster; John Leslie; Bob Briscoe; Woundy, Richard; Mcdysan,
> David E
> *Cc:* [email-masked]
>
> *Subject:* comments/suggestions on draft-ietf-conex-concepts-uses-01
>
>
>
> “We argue that congestion needs.... More specifically, a network needs to
> be able to measure how much congestion any particular traffic expects to
> cause between the monitoring point in the network and the destination

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 25 Mar 2011 09:37:04 +0100

In my reading of section 6, it presents 2 distinct issues:

1) Long time scales: A use case (or perhaps a few variations on the  
same use case) for the conex signal as currently described in abstract- 
mech, wherein conex helps network operators to manage congestion,  
conduct traffic shaping, and capacity-plan over periods much longer  
than network speeds (e.g., minutes/hours/days/months)

2) Shaper presence: A suggestion that conex could signal the presence  
of a traffic shaper (in addition to or instead of how the conex signal  
is currently described in abstract-mech) and a use case for such a  
signal wherein recipients of the signal can use it to request that  
sender's traffic shaper parameters be altered

I think the issue of long time scales, which is described in the  
introductory text to section 6 and briefly in 6.1 and 6.2, could  
instead be succinctly addressed by adding a couple of sentences to 5.1  
to explain that the use of conex for managing "heavy" users could  
occur over shorter or longer time scales and could have the added  
affect of helping operators to do longer-term capacity planning.

Signaling the presence of a shaper seems to me to be a separate animal  
altogether, and one over which there is some obvious disagreement. But  
at least half of section 6 seems to be devoted to the idea that  
operators would have uses for aggregating conex information over long  
time frames, and I think those uses could be incorporated with a brief  
addition to section 5.1.

Alissa

On Mar 17, 2011, at 12:25 PM, Mcdysan, David E wrote:

> Hi Nandita,
>
> A few responses to your questions on the new section in line below  
> prefixed by DM which were previously posted to the list that I  
> believe (at least partially) address your comments.
>
> I propose that the working group work toward how to organize/merge/ 
> move the new text better into the existing outline.
>
> Thanks,
>
> Dave
>
> From: Nandita Dukkipati <[email-masked]>
> To: Toby Moncaster <[email-masked]>, John Leslie <[email-masked]>,  
> Bob Briscoe <[email-masked]>, "Woundy, Richard" <[email-masked] 
> >, David McDysan <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> On reading the latest draft, I have three high level comments  
> roughly in the following order of importance-
>
> ***
> * What is _the_ main point? How about starting the section by  
> stating your main point upfront as opposed leaving it to the reader  
> to figure it out.
>
> * Why and how is this use case distinct from that of traffic  
> management which already seems to have a broad scope? Is it really  
> distinct?
>
> DM – the minutes recorded adding the agreement to add this as a new  
> section. (A new subsection, and or merging thoughts with other use  
> cases (e.g., as suggested above) is what I believe the wg needs to  
> discuss.
>
> ***
> “We argue that congestion needs.... More specifically, a network  
> needs to be able to measure how much congestion any particular  
> traffic expects to cause between the monitoring point in the network  
> and the destination ("rest-of-path congestion"). This would be a new  
> capability.”
>
> information at any given node is not sufficient. Why does a node  
> require congestion information from a monitoring point to the  
> destination to be able to manage its own congestion? A succinct  
> explanation and/or an example will go a long way.
>
> _______________________________________________
> conex mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/conex