Re: [aqm] PIE & CableLabs

"Eggert, Lars" <lars@netapp.com> Fri, 08 November 2013 21:22 UTC

Return-Path: <lars@netapp.com>
X-Original-To: aqm@ietfa.amsl.com
Delivered-To: aqm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3060311E8112 for <aqm@ietfa.amsl.com>; Fri, 8 Nov 2013 13:22:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.75
X-Spam-Level:
X-Spam-Status: No, score=-4.75 tagged_above=-999 required=5 tests=[AWL=-2.378, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GmDv-OI2HXlr for <aqm@ietfa.amsl.com>; Fri, 8 Nov 2013 13:22:10 -0800 (PST)
Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 5029311E80DE for <aqm@ietf.org>; Fri, 8 Nov 2013 13:22:10 -0800 (PST)
X-IronPort-AV: E=Sophos; i="4.93,662,1378882800"; d="p7s'?scan'208"; a="71828317"
Received: from vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) by mx11-out.netapp.com with ESMTP; 08 Nov 2013 13:22:08 -0800
Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.51]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.03.0158.001; Fri, 8 Nov 2013 13:22:08 -0800
From: "Eggert, Lars" <lars@netapp.com>
To: Greg White <g.white@cablelabs.com>
Thread-Topic: [aqm] PIE & CableLabs
Thread-Index: AQHO3MAAFFH8PuCBIk6ZSa6cse1IYpobvoAAgACfOoA=
Date: Fri, 08 Nov 2013 21:22:07 +0000
Message-ID: <17BA4215-B855-4424-9D8C-FCFE11A1849E@netapp.com>
References: <CEA2994A.21C54%g.white@cablelabs.com>
In-Reply-To: <CEA2994A.21C54%g.white@cablelabs.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.104.60.116]
Content-Type: multipart/signed; boundary="Apple-Mail=_5CAC4D28-EE66-4799-8110-B1D0EB749B27"; protocol="application/pkcs7-signature"; micalg="sha1"
MIME-Version: 1.0
Cc: "aqm@ietf.org" <aqm@ietf.org>, Ralph Droms <rdroms.ietf@gmail.com>
Subject: Re: [aqm] PIE & CableLabs
X-BeenThere: aqm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion list for active queue management and flow isolation." <aqm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aqm>, <mailto:aqm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/aqm>
List-Post: <mailto:aqm@ietf.org>
List-Help: <mailto:aqm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aqm>, <mailto:aqm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Nov 2013 21:22:17 -0000

Hi,

On 08 Nov 2013, at 12:52, Greg White <g.white@cablelabs.com> wrote:
> 1) Yes, CableLabs has settled on a formal specification.  It can be found
> in Annex M of 
> http://www.cablelabs.com/specifications/CM-SP-MULPIv3.1-I01-131029.pdf
> 
> 2) see above.

great, thanks Greg!

> 3) Probably not directly. We have requested that Cisco update the PIE I-D
> to include the updates to the core PIE algorithm made as part of the
> CableLabs evaluation. CableLabs will draft an I-D to cover the remaining
> gaps between that and what can be found in 1.  I think this achieves what
> you are after.  Let me know if not.

That sounds like pretty good plan.

One remaining question is what will happen if the AQM WG - after adopting the PIE contribution - makes modifications. Is CableLabs prepared to update their specs based on whet we'll do, referring to an eventual IETF RFC rather than maintaining a separate spec? Or will CableLabs also continue work on the spec and we may end up with eventual divergence? (Or will the CableLabs spec of PIE remain frozen at its current version?)

Having asked that, I want to make clear that the working relationship with CableLabs has been good, and it's not that I'm expecting problems here. It's after all - at least at the moment - the same people working on PIE here and there. It's just that I've been involved in cases in the IETF before where things fell through the cracks when two SDOs simultaneously worked on something, and it's messy to create alignment after that has happened. So an explicit agreement about how this will go forward would be good to have.

Thanks,
Lars