Re: [re-ECN] Two questions about CONEX

"Woundy, Richard" <Richard_Woundy@cable.comcast.com> Sat, 08 May 2010 13:42 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 2509A3A6A8C for <re-ecn@core3.amsl.com>; Sat, 8 May 2010 06:42:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.271
X-Spam-Level:
X-Spam-Status: No, score=-0.271 tagged_above=-999 required=5 tests=[AWL=-2.408, 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 4MxLdWOS16pi for <re-ecn@core3.amsl.com>; Sat, 8 May 2010 06:42:00 -0700 (PDT)
Received: from paoakoavas09.cable.comcast.com (paoakoavas09.cable.comcast.com [208.17.35.58]) by core3.amsl.com (Postfix) with ESMTP id 399C03A6A8A for <re-ecn@ietf.org>; Sat, 8 May 2010 06:41:59 -0700 (PDT)
Received: from ([24.40.15.92]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.90905255; Sat, 08 May 2010 09:41:30 -0400
Received: from pacdcexcmb05.cable.comcast.com ([24.40.15.116]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 8 May 2010 09:41:30 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Sat, 08 May 2010 09:40:37 -0400
Message-ID: <EE00404438E9444D90AEA84210DC406707FB24@pacdcexcmb05.cable.comcast.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [re-ECN] Two questions about CONEX
Thread-Index: AcrudyJVMru7wvSAS6K8uSlWogeisAAO4dEK
References: <4BE5039A.5040003@cisco.com>
From: "Woundy, Richard" <Richard_Woundy@cable.comcast.com>
To: stbryant@cisco.com, re-ecn@ietf.org
X-OriginalArrivalTime: 08 May 2010 13:41:30.0970 (UTC) FILETIME=[2A9963A0:01CAEEB4]
Subject: Re: [re-ECN] Two questions about CONEX
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: Sat, 08 May 2010 13:42:01 -0000

So a couple of questions back to you.
 
1. I gave the 'CMTS congestion management' as a representative example. But what if I need similar measurements/mechanisms at my backbone interconnects? (That's probably the second place I would need to worry about congestion.) Can these OAM messages make it there?
 
2. A typical subscriber host is behind one (or more) Ethernet/WiFi home gateways, then behind a broadband modem that may or may not use Ethernet as a layer two transport over the broadband access network. So are we talking about a layer 2 or 3 OAM message? If layer 3, how would a host behind a NAT know who to address it to? (I don't personally like NAT66 but that may be the subscriber's choice rather than mine.) If layer 2, how do I get the subscriber to upgrade all of their home CPE? Plus how many layer 2 technologies need to define this OAM message? Or do we need to define a new home network layer 2 (please no)?
 
3. What if the OAM message needs to be originated by the application/content server side, rather than the subscriber side? How would that server know which CMTS / interconnect router to send it to?
 
-- Rich
 
P.S. The long time constant in the CMTS congestion management feedback loop is dependent on the state of the art today (DOCSIS specs require 15 minute IPDR polling cycle support for the CMTS). In some ways this is a bug, in some ways this is a feature. :)

________________________________

From: re-ecn-bounces@ietf.org on behalf of Stewart Bryant
Sent: Sat 5/8/2010 2:24 AM
To: re-ecn@ietf.org
Subject: [re-ECN] Two questions about CONEX




As I was reading the recent email on CONEX I got the impression that a
lot of the interest in CONEX is to instrument the network so that
operators can identify the root causes of congestion and understand the
impact on the network in more detail.

  I also get the impression that at least some of the operators are
looking for a relatively long time constant in the feedback loop.

That causes me to wonder where CONEX fits in relative to IPFIX which is
a mechanism that is designed to monitor the flows in a network and
report this information to the network operator.

As I noted in a earlier thread, I am also interested in understanding
why the host needs to use the data packets themselves to indicate the
expected congestion state to the network rather than using a fate
sharing OAM mechanism?

- Stewart





_______________________________________________
re-ECN mailing list
re-ECN@ietf.org
https://www.ietf.org/mailman/listinfo/re-ecn