Re: [re-ECN] Conex charter - now in External Review

"Woundy, Richard" <Richard_Woundy@cable.comcast.com> Thu, 29 April 2010 22:04 UTC

Return-Path: <richard_woundy@cable.comcast.com>
X-Original-To: re-ecn@core3.amsl.com
Delivered-To: re-ecn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C9A03A682F for <re-ecn@core3.amsl.com>; Thu, 29 Apr 2010 15:04:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.334
X-Spam-Level:
X-Spam-Status: No, score=-0.334 tagged_above=-999 required=5 tests=[AWL=-2.471, BAYES_50=0.001, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cWkTDl3O4zo for <re-ecn@core3.amsl.com>; Thu, 29 Apr 2010 15:04:32 -0700 (PDT)
Received: from paoakoavas09.cable.comcast.com (paoakoavas09.cable.comcast.com [208.17.35.58]) by core3.amsl.com (Postfix) with ESMTP id A8DC23A67D7 for <re-ecn@ietf.org>; Thu, 29 Apr 2010 15:04:31 -0700 (PDT)
Received: from ([10.195.246.152]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.90513269; Thu, 29 Apr 2010 18:03:58 -0400
Received: from pacdcexcmb05.cable.comcast.com ([24.40.15.116]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Apr 2010 18:03:58 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 29 Apr 2010 18:03:13 -0400
Message-ID: <EE00404438E9444D90AEA84210DC4067A377B9@pacdcexcmb05.cable.comcast.com>
In-Reply-To: <4BD9408E.7090201@cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [re-ECN] Conex charter - now in External Review
Thread-Index: AcrndGbYnhQP5oLITkaKEzCXU5vv/AAO3A8g
References: <4BD6F2DD.3040202@cisco.com> <20100427151601.GF16203@verdi> <EE00404438E9444D90AEA84210DC406793D9DB@pacdcexcmb05.cable.comcast.com> <A8B8C5AF-37C2-4DD6-BDDB-760FC616BE8F@g11.org.uk> <EE00404438E9444D90AEA84210DC406793DC75@pacdcexcmb05.cable.comcast.com> <20100428152122.GB14169@verdi> <4BD9408E.7090201@cisco.com>
From: "Woundy, Richard" <Richard_Woundy@cable.comcast.com>
To: stbryant@cisco.com, John Leslie <john@jlc.net>
X-OriginalArrivalTime: 29 Apr 2010 22:03:58.0148 (UTC) FILETIME=[DDFFF040:01CAE7E7]
Cc: re-ecn@ietf.org
Subject: Re: [re-ECN] Conex charter - now in External Review
X-BeenThere: re-ecn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: re-inserted explicit congestion notification <re-ecn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/re-ecn>, <mailto:re-ecn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/re-ecn>
List-Post: <mailto:re-ecn@ietf.org>
List-Help: <mailto:re-ecn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/re-ecn>, <mailto:re-ecn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Apr 2010 22:04:33 -0000

> If the intent is to design a mechanism that works under the assumption
that congestion state will normally only be visible at network
boundaries, then that should be in the charter. If the intent is not to
make that assumtion, then we should have a very high degree of
confidence that we can find a viable MPLS solution.

Very good question.

In my personal view, I would consider *where* congestion typically
occurs. In a broadband ISP's network (broadband access + regional access
+ backbone + interconnects), my assertion on this mailing list has been
that when congestion occurs, it usually occurs over or close to the last
mile broadband access network (eg over the DOCSIS network, or between
the DSLAM and BRAS, to pick two examples). Congestion happens less
frequently over interconnects between ISPs, and finally in rare
instances congestion occurs over internal links within the ISP's
regional access networks / backbone. So my assertion implies that the
"interesting congestion" occurs at the network boundaries.

To be fair, I can't say that everyone here would agree with that set of
assumptions.

-- Rich

-----Original Message-----
From: Stewart Bryant [mailto:stbryant@cisco.com] 
Sent: Thursday, April 29, 2010 4:17 AM
To: John Leslie
Cc: Woundy, Richard; ken carlberg; re-ecn@ietf.org
Subject: Re: [re-ECN] Conex charter - now in External Review


>     (I also note that Stewart asked about MPLS forwarding: that's a
> quite separate question which may deserve more of an answer than
> I have already given...)
Let me explain why I keep asking about MPLS.

The stated purpose of CONEX is to provide visibility of congestion state

within the network.

A very large fraction of provider networks use MPLS as their primary 
forwarding mechanism.

In those networks there will only be visibility of the congestion state 
at the network ingress and egress unless an MPLS solution is designed.

If the intent is to design a mechanism that works under the assumption 
that congestion state will normally only be visible at network 
boundaries, then that should be in the charter. If the intent is not to 
make that assumtion, then we should have a very high degree of 
confidence that we can find a viable MPLS solution.

Bob's answer to MPLS in Anaheim was to take it out of scope, but that 
does not address  the central of whether the technology is viable for 
deployment without MPLS support.

- Stewart