Re: [re-ECN] Two questions about CONEX

ken carlberg <carlberg@g11.org.uk> Mon, 10 May 2010 20:44 UTC

Return-Path: <carlberg@g11.org.uk>
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 E510D3A68F6 for <re-ecn@core3.amsl.com>; Mon, 10 May 2010 13:44:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.619
X-Spam-Level:
X-Spam-Status: No, score=-0.619 tagged_above=-999 required=5 tests=[AWL=0.491, BAYES_05=-1.11]
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 mYAjmYWAkOoO for <re-ecn@core3.amsl.com>; Mon, 10 May 2010 13:44:35 -0700 (PDT)
Received: from portland.eukhost.com (portland.eukhost.com [92.48.97.5]) by core3.amsl.com (Postfix) with ESMTP id 9078E3A6A86 for <re-ecn@ietf.org>; Mon, 10 May 2010 13:38:26 -0700 (PDT)
Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:61611 helo=[192.168.0.20]) by portland.eukhost.com with esmtpa (Exim 4.69) (envelope-from <carlberg@g11.org.uk>) id 1OBZjv-0000DU-LQ; Mon, 10 May 2010 20:38:11 +0000
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset="us-ascii"
From: ken carlberg <carlberg@g11.org.uk>
In-Reply-To: <4BE85D4C.3030001@juniper.net>
Date: Mon, 10 May 2010 16:38:12 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <F561D0B8-0B94-4C8C-943A-3B44E4D81BD3@g11.org.uk>
References: <4BE5039A.5040003@cisco.com> <EE00404438E9444D90AEA84210DC406707FB24@pacdcexcmb05.cable.comcast.com> <4BE5A010.3000402@cisco.com> <EE00404438E9444D90AEA84210DC406707FB28@pacdcexcmb05.cable.comcast.com> <4BE85D4C.3030001@juniper.net>
To: Ron Bonica <rbonica@juniper.net>
X-Mailer: Apple Mail (2.1078)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - portland.eukhost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - g11.org.uk
Cc: re-ecn@ietf.org
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: Mon, 10 May 2010 20:44:37 -0000

I'm sorry for getting lost, but how does capturing use cases produce or correlate to a problem statement?  And given that topic, could you then expand on the issues you have with the current Conex problem statement?

Outside of that, I look forward to reading your contribution(s) to this new effort you are in favor of.

kindest regards,

-ken



On May 10, 2010, at 3:23 PM, Ron Bonica wrote:

> Richard,
> 
> I like this proposal. *alot*.
> 
> I think that we should charter a WG and task that WG with the
> development of exactly one document. That document captures use cases in
> which the ip-layer does something useful with congestion information.
> (This is currently out of scope for CONEX).
> 
> When that WG has completed its work, we should have another BoF in which
> multiple solutions (including CONEX) can be entertained.
> 
> I don't know if there will be any other solutions, but it's always a
> good idea to put the problem statement ahead of the solution.
> 
>                                    Ron
> 
> 
> On 5/10/2010 8:23 AM, Woundy, Richard wrote:
>> If folks in general (not just the IESG) think there are a lot of alternatives 
> to Conex, maybe the ADs should form a design team that uses a real-time
> form of
> communication to talk this through? I'm thinking any combination of f2f
> meeting,
> conference call, or Webex to start...
>> 
>> -- Rich
>> 
>> ________________________________
>> 
>> From: Stewart Bryant [mailto:stbryant@cisco.com]
>> Sent: Sat 5/8/2010 1:32 PM
>> To: Woundy, Richard
>> Cc: re-ecn@ietf.org
>> Subject: Re: [re-ECN] Two questions about CONEX
>> 
>> 
>> 
>> On 08/05/2010 14:40, Woundy, Richard wrote:
>>> 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?
>>> 
>> That would depend on how they are carried. For example (and only for
>> example) if they were embedded in the transport protocol itself they
>> would go where ever the transport went.
>> 
>> 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)?
>> 
>> See above.
>>> 
>>> 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?
>>> 
>> See above.
>>> 
>>> -- 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. :)
>>> 
>> I agree, but I was not thinking of 15mins, on the other hand I was not
>> thinking of packet rate which is where I believe current thinking is.
>> 
>> - Stewart
>> 
>> 
>>> ________________________________
>>> 
>>> 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
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> --
>> For corporate legal information go to:
>> 
>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>> 
>> 
>> 
>> 
>> _______________________________________________
>> re-ECN mailing list
>> re-ECN@ietf.org
>> https://www.ietf.org/mailman/listinfo/re-ecn
>> .
>> 
> _______________________________________________
> re-ECN mailing list
> re-ECN@ietf.org
> https://www.ietf.org/mailman/listinfo/re-ecn