Subject: [conex] FW: New Version Notification for draft-moncaster-conex-concepts-uses-00

From: "Toby Moncaster" <[email-masked]>
Date: Thu, 1 Jul 2010 21:47:53 +0100

All,

I have just posted this revised document, addressing most of Marcelo's comments. Notice the new filename and title... There is a changelog in the draft and there is a link to the diff below...

HTML at http://www.moncaster.com/conex/draft-moncaster-conex-concepts-uses-00.html

DIFF at http://www.moncaster.com/conex/Diff0.htm

I think this is now in a good enough state to be adopted as the first WG document. The changes make this pretty close to what is requested in the charter (namely a use cases document). There is a section on mechanisms because to my mind a use cases document with no description of mechanism is useless (as there would be no way for people to judge how realistic the use cases are).

So, to ask the question formally, does anyone else think this is ready for WG adoption? What do the chairs think? Will the chairs propose this for adoption or do you intend to wait until it has been discussed at Maastricht?

Toby

PS Dirk, I saw your email (or skimmed it anyway), but it was too late to incorporate your suggestions into this release. Hopefully I will have time next week to do another revision and will probably incorporate the majority of your suggestions

> -----Original Message-----
> From: IETF I-D Submission Tool [mailto:[email-masked]]
> Sent: 01 July 2010 21:39
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: New Version Notification for draft-moncaster-conex-concepts-
> uses-00
> 
> 
> A new version of I-D, draft-moncaster-conex-concepts-uses-00.txt has
> been successfully submitted by Toby Moncaster and posted to the IETF
> repository.
> 
> Filename:	 draft-moncaster-conex-concepts-uses
> Revision:	 00
> Title:		 ConEx Concepts and Use Cases
> Creation_date:	 2010-07-01
> WG ID:		 Independent Submission
> Number_of_pages: 20
> 
> Abstract:
> Internet Service Providers (ISPs) are facing problems where
> congestion prevents full utilization of the path between sender and
> receiver at today's "broadband" speeds.  ISPs desire to control the
> congestion, which often appears to be caused by a small number of
> users consuming a large amount of bandwidth.  Building out more
> capacity along all of the path to handle this congestion can be
> expensive; and network operators have sought other ways to manage
> congestion.  The current mechanisms all suffer from difficulty
> measuring the congestion (as distinguished from the total traffic).
> 
> The ConEx Working Group is designing a mechanism to make congestion
> along any path visible at the Internet Layer.  This document
> discusses this mechanism.
> 
> 
> 
> The IETF Secretariat.

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 2 Jul 2010 12:24:55 +0100

Hi Toby,

Just a note on section 3, I think it would help to at least list  
current approaches to congestion management by name (as was done in  
both draft-moncaster-congestion-exposure-problem-03 and draft- 
tschofenig-conex-ps-02) so that readers of this document understand  
what they're supposed to be comparing conex-enabled mechanisms  
against. As it is the draft talks about "all of the current  
approaches" in several places, but it's not clear what that group is  
referring to.

One question inline...

On Jul 1, 2010, at 9:47 PM, Toby Moncaster wrote:
> I think this is now in a good enough state to be adopted as the  
> first WG document. The changes make this pretty close to what is  
> requested in the charter (namely a use cases document). There is a  
> section on mechanisms because to my mind a use cases document with  
> no description of mechanism is useless (as there would be no way for  
> people to judge how realistic the use cases are).

Are you thinking that what is explained in section 6 would be the  
abstract specification of the mechanism that the WG is chartered to  
do, or would that be specified in a separate document?

Thanks,
Alissa

>
> So, to ask the question formally, does anyone else think this is  
> ready for WG adoption? What do the chairs think? Will the chairs  
> propose this for adoption or do you intend to wait until it has been  
> discussed at Maastricht?
>
> Toby
>
> PS Dirk, I saw your email (or skimmed it anyway), but it was too  
> late to incorporate your suggestions into this release. Hopefully I  
> will have time next week to do another revision and will probably  
> incorporate the majority of your suggestions
>
> _______________________________________________
> conex mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/conex
>

---

From: "Toby Moncaster" <[email-masked]>
Date: Fri, 2 Jul 2010 13:06:32 +0100

Hi Alissa,

Inline responses

Toby

> From: Alissa Cooper [mailto:[email-masked]]
> Sent: 02 July 2010 12:25
> To: Toby Moncaster
> Cc: [email-masked]
> Subject: Re: [conex] FW: New Version Notification for draft-moncaster-
> conex-concepts-uses-00
> 
> Hi Toby,
> 

That is a reasonable point. We (co-authors) were unsure how much detail to
go into on current approaches. I will try and improve this section and
remove ambiguities when the next version comes out

> do, or would that be specified in a separate document?

I am expecting there to be a separate document specifying the actual
mechanism. This section is intended to give sufficient detail of a possible
approach to allow people to see how realistic conex is. Currently re-ECN is
the only mechanism that has been proposed, hence that is the mechanism I am
assuming for these use cases...

---

From: Leslie Daigle <[email-masked]>
Date: Mon, 26 Jul 2010 12:53:49 -0400

Hi,

A couple of general comments --

I like the way the description of what congestion exposure actually is 
has evolved -- it seems much crisper.

I'm afraid I still see 2 documents here, for the sake of continued 
relevance and clarity beyond current audiences.

More detail --

I believe my comment from the earlier document still stands:

[On March 7, I wrote:]
> Reading through the document again, I was struck by the focus on
> "ISPs".  Perhaps one of the ways to emphasize the "inter-network"
> aspect of this proposal is to back out of that:  remove all instances
> of "ISP" in this document, and focus the text on networks, whatever
> their type.

The first paragraph of the document now refers to "network operators', 
which is probably as reasonable a generalization as any to replace ISP 
-- could be mobile data networks, could be educational/research 
networks, etc.

This is perhaps one instance of a more fundamental issue, in my opinion: 
  I understand Bob's argument that the use cases and mechanisms are 
commonly understood when discussed together.  But I think that keeping 
them together in the same document (even following Marcelo's proposed 
restructuring) is going to unnecessarily limit understanding of the 
concepts:  they will be _too_ tied to the use cases.

This is reflected in the other thread about whether this is congestion 
exposure for [excessive] congestion management, or for capacity sharing.

IMO:  when someone is referring back to the canonical CONEX documents in 
5 years, they should be able to read the RFC that describes the CONEX 
mechanisms, without having to mentally subtract the use case 
illustrations that are relevant today, but perhaps distracting tomorrow.

To try to be a bit clearer of how I would see this as two documents, I 
could suggest:

Mechanisms, with a new introduction and keeping 2, 4, 5, and 7 
(s/ISP/network operator/g)

Uses, keeping 1, 8, and 9

I'm not sure I understand that section 6 was fully motivated to be 
included in either document.

Leslie.

Toby Moncaster wrote:
> All,
> 
> I have just posted this revised document, addressing most of 
> Marcelo's comments. Notice the new filename and title... There is a 
> changelog in the draft and there is a link to the diff below...
> 
> HTML at 
> http://www.moncaster.com/conex/draft-moncaster-conex-concepts-uses-00.html
> 
> 
> 
> I think this is now in a good enough state to be adopted as the first
>  WG document. The changes make this pretty close to what is requested
>  in the charter (namely a use cases document). There is a section on 
> mechanisms because to my mind a use cases document with no 
> description of mechanism is useless (as there would be no way for 
> PS Dirk, I saw your email (or skimmed it anyway), but it was too late
>  to incorporate your suggestions into this release. Hopefully I will 
> have time next week to do another revision and will probably 
>> -----Original Message----- From: IETF I-D Submission Tool 
>> [mailto:[email-masked]] Sent: 01 July 2010 21:39 To: 
>> [email-masked] Cc: [email-masked]; 
>> [email-masked]; [email-masked] Subject: New Version
>>  Notification for draft-moncaster-conex-concepts- uses-00
>> 
>> 
>> A new version of I-D, draft-moncaster-conex-concepts-uses-00.txt 
>> has been successfully submitted by Toby Moncaster and posted to the
>>  IETF repository.
>> 
>> Filename:	 draft-moncaster-conex-concepts-uses Revision:	 00 Title:
>>  ConEx Concepts and Use Cases Creation_date:	 2010-07-01 WG ID: 
>> Independent Submission Number_of_pages: 20
>> 
>> Abstract: Internet Service Providers (ISPs) are facing problems 
>> where congestion prevents full utilization of the path between 
>> sender and receiver at today's "broadband" speeds.  ISPs desire to 
>> control the congestion, which often appears to be caused by a small
>>  number of users consuming a large amount of bandwidth.  Building 
>> out more capacity along all of the path to handle this congestion 
>> can be expensive; and network operators have sought other ways to 
>> manage congestion.  The current mechanisms all suffer from 
>> difficulty measuring the congestion (as distinguished from the 
>> total traffic).
>> 
> _______________________________________________ conex mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/conex
> 

-- 

-------------------------------------------------------------------
"Reality:
      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle
[email-masked]
-------------------------------------------------------------------

---

From: "Mcdysan, David E" <[email-masked]>
Date: Tue, 27 Jul 2010 02:47:09 -0400

I had a similar thought reading this document -- it actually contains a
relatively small amount of material on use cases, more material on
concepts, and the majority of the document is on on a mechanism.

>From the charter, use cases is the first deliverable (with primarily a
focus on the intra-network scenario), while the description of an
abstract specification is the second major deliverable.

Thanks,

Dave

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Leslie Daigle
> Sent: Monday, July 26, 2010 12:54 PM
> To: Toby Moncaster
> Cc: [email-masked]
> Subject: Re: [conex] FW: New Version Notificationfor 
> draft-moncaster-conex-concepts-uses-00
> 
> 
> Hi,
> 
> 
> I like the way the description of what congestion exposure 
> actually is has evolved -- it seems much crisper.
> 
> I'm afraid I still see 2 documents here, for the sake of 
> continued relevance and clarity beyond current audiences.
> 
> 
> More detail --
>