Re: [re-ECN] Two questions about CONEX

ken carlberg <carlberg@g11.org.uk> Mon, 10 May 2010 15:29 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 A22A13A6971 for <re-ecn@core3.amsl.com>; Mon, 10 May 2010 08:29:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.071
X-Spam-Level:
X-Spam-Status: No, score=-0.071 tagged_above=-999 required=5 tests=[AWL=-0.072, BAYES_50=0.001]
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 Yrk-gmyfOQJQ for <re-ecn@core3.amsl.com>; Mon, 10 May 2010 08:29:28 -0700 (PDT)
Received: from portland.eukhost.com (portland.eukhost.com [92.48.97.5]) by core3.amsl.com (Postfix) with ESMTP id 0DA563A6A13 for <re-ecn@ietf.org>; Mon, 10 May 2010 08:27:33 -0700 (PDT)
Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:59867 helo=[192.168.0.20]) by portland.eukhost.com with esmtpa (Exim 4.69) (envelope-from <carlberg@g11.org.uk>) id 1OBUt2-0001d6-SI; Mon, 10 May 2010 15:27:17 +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: <4BE81C57.3000405@cisco.com>
Date: Mon, 10 May 2010 11:27:17 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <D5CA2796-7AE1-4F40-B890-9534D3C9F1E8@g11.org.uk>
References: <4BE5039A.5040003@cisco.com> <EE00404438E9444D90AEA84210DC406707FB24@pacdcexcmb05.cable.comcast.com> <4BE5A010.3000402@cisco.com> <EE00404438E9444D90AEA84210DC406707FB28@pacdcexcmb05.cable.comcast.com> <94C91C87-3626-4ED4-9DEE-CC21F16D835A@g11.org.uk> <4BE81C57.3000405@cisco.com>
To: stbryant@cisco.com
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: "Woundy, Richard" <Richard_Woundy@cable.comcast.com>, 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 15:29:29 -0000

Stewart,

I appreciate the added clarity, and its a fair question to ask.  My own impression is that one could/should have some wiggle room to report the congestion state in some subset of packets to provide hints versus a granular in-depth approach of relying on state placed in every packet.  I assume your concern stems from a possible excess examination of state, which is fair concern.  Ideally, information gleaned from the experimental status of the effort would inform us if the effectiveness of Conex is only tangible if the congestive state is reported in every packet during that condition. 

but before I box myself into a corner :-), an acceptance of different modes of operation doesn't (in my opinion) place the effort as purely research.  rather, its an identification of one item that needs to be fleshed out in this role as an IETF experimental effort.  your follow up statement of...

> Please remember that part of the problem here is to test whether CONEX is sufficiently 
> cooked that it is an engineering problem, or whether it is still a research phase problem.

...is also an understandable one to press the group on.  My understanding is that the lads at BT have pushed this beyond just a research phase such that we at least have a specific direction to aim at.  Do we have a bleeding edge engineering effort being placed on our lap?  Probably.   But my impression is that this falls within the scope of what an experimental IETF effort should be.  Certainly, the proposed CONEX effort is nothing near to what was put forward with IPv5 and the Stream Protocol -- another experimental effort of ages ago.

cheers,

-ken


On May 10, 2010, at 10:46 AM, Stewart Bryant wrote:

> I would like to clarify what my concern is here.
> 
> If the marking is in every packet then the forwarder needs to take action on every packet.
> 
> The thing that makes IP (and MPLS) cheap and fast is that we only do the minimum amount of processing in forwarding and do as much as we can by other means. In particular everything other than forwarding happens at a much slower rate, is often asynchronous WRT forwarding, and usually happens in a process that can schedule the processing at some convenient time.
> 
> I used the term OAM rather loosely earlier to indicate a packet that traversed the path, fate sharing with the data, containing information of note intended for the intermediate systems.  I make no comment on how such packets might be carried or fate shared.
> 
> My question here is that whilst I can see that we need to do better than the 15mins that systems seem to do at the moment, do we need to go all the way to making the reporting the congestion state on every packet.
> 
> - Stewart
> 
> 
> 
> On 10/05/2010 14:17, ken carlberg wrote:
>> just a couple of various thoughts....
>> 
>> if there are alternatives to Conex, cool.  It would be nice to hear people volunteering for a design team and see what they come up with.  But i think that effort then probably needs to go to the IETF list to kick it off for wider distribution/advertisement, and then possibly have another list to go into the specifics and start separate BoF.
>> 
>> I found that I agreed a fair amount what was previously sent to the list by Kevin Mason.  I'd add that if OAM was the direction to take, then isn't the direction of a solution now being pared down to the boundaries of a specific transit -- and really just the leaf transit?  My impression with Conex was that it was not constrained (even policy-wise) to a single transit but was independent to that because we are placing the info in the IP packet.  But please correct me if I'm missing something.
>> 
>> -ken
>> 
>> 
>> 
>> On May 10, 2010, at 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
>>>     
>> 
>>   
> 
> 
> -- 
> For corporate legal information go to:
> 
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
> 
>