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

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

Apologies to everyone, especially Nandita and Dave. This was not meant to go
to the conex list as I am sure you will all realise.

I was just letting off some steam, principally caused by other things
happening in my life...

Again, apologies if I caused anyone any offence...

Toby

From: Toby Moncaster [mailto:[email-masked]] 
Sent: 17 March 2011 09:55
To: 'John Leslie'
Cc: [email-masked]'
Subject: RE: comments/suggestions on draft-ietf-conex-concepts-uses-01

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

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.