Re: [conex] Genart LC review: draft-ietf-conex-abstract-mech-12

Matt Mathis <> Thu, 07 August 2014 00:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 978C81A02E6 for <>; Wed, 6 Aug 2014 17:02:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dhwC7ogDsISk for <>; Wed, 6 Aug 2014 17:02:30 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 62B101B2886 for <>; Wed, 6 Aug 2014 17:02:30 -0700 (PDT)
Received: by with SMTP id wp4so2373044obc.29 for <>; Wed, 06 Aug 2014 17:02:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YhHpVIVU32CgKXxp2h+FjEauKu96TPfmUi9yjNQL8g4=; b=KcFuN//fVYcN9eaM5UR/5gWto79h2O2JY2RK7yK6fHtJlRo+qSkTE2xUWwUtyvHH6L sicdLBWmbWn5Xnkh9zkf8krHoiGcIe1b+PVBGczOiS3MfpnD+YXSURGj8MNFBWteaN4J v4LQw112G9JJWJ7Bly7+rjLl2GRRdSmNDYnkzLko7AuzMY21h2b8tvNqCU3mfCCJWGqC BCITMe5v0UXg+S3h+do7Ed20Da8k8ttZ1QWIgNO688cA5zYSbmjWngZ0KPW7VwD7OrfU gBu/ISAEnq7zC0+cmQ6CYuNuoNjtD6YaIESecxihKCaD/JrmguslmBhWf2YDUblLzwpB D8Bg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=YhHpVIVU32CgKXxp2h+FjEauKu96TPfmUi9yjNQL8g4=; b=BFj05H5eTZhfLO6EoyBltAeyjYLTYSxD/4FCfxaj4cWuw1DOWGwZ6sj4b4W8oZ3pFg 2i2SuZPBnnckg8MFNSq0lu8qiT9zhIZaAY1XGuG3XQ55ooYJ8RcEmHFNHPjw4LIfje60 AOk7sTFY3+NTjGaQ5BbddBkNaTFTj+T+K1E7MvCI2qNz3shrxXz4ED8MKtGB2Wro3CdC MOx16QRmQfmdo8Hbq4Y8U9COUnAziygpUohv5J77HY0N2Rd0fTAJ/xyEM3CD3Lo3LbmT 77dB3LxirohMQWgs9pxRdbT3tlhKYrkFICN3CklOtDv8ypsAqfsh9KIFRrwtz8MEqVg2 tHaA==
X-Gm-Message-State: ALoCoQkSZF0s00YvOCVhA5wGj/Th0Z42ilDpXe5SBN4xTYlDJgexMnHYozaBjCTUArsb83S59P8N
MIME-Version: 1.0
X-Received: by with SMTP id ja7mr18911330obb.74.1407369749694; Wed, 06 Aug 2014 17:02:29 -0700 (PDT)
Received: by with HTTP; Wed, 6 Aug 2014 17:02:29 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Wed, 06 Aug 2014 17:02:29 -0700
Message-ID: <>
From: Matt Mathis <>
To: Robert Sparks <>
Content-Type: multipart/alternative; boundary="089e012954dcffb32a04fffecded"
Cc: General Area Review Team <>, "" <>,, ConEx IETF list <>
Subject: Re: [conex] Genart LC review: draft-ietf-conex-abstract-mech-12
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Congestion Exposure working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 07 Aug 2014 00:02:32 -0000

You are correct, the section is a bit stale.  And although the authors of
6789 would like to claim the topic is closed, newer documents
(e.g. draft-ietf-tcpm-accecn-reqs-07.txt,) have found it necessary to hedge
on this very issue for pragmatic reasons.  (Note the overlapping authors
between -abstract-mech-, 6789 and -accecn-).

The core advice in section 4.6 still stands:
> "This document does not take a strong position on this issue.    However,
> a ConEx encoding will need to explicitly specify whether it assumes units
> of bytes or packets consistently for both congestion indications and ConEx
> markings.  (see network layer requirement E in Section 3.3)."

Some of the surrounding editorializing reflects not completely resolved
tension between the authors on this point.  I for one would prefer to
remove the presumption that 6789 and 7141 are the final answer, and make
this draft purely bytes/packets agnostic.  I partially ceded the point on
the grounds that the impracticality 6789 would doom it over the long haul,
as we have already seen in -accecn-.

It would be bad form for this document to explicitly conflict with 6789,
but I for one would object to it unequivocally endorsing 6789, and although
leaving it waffle, isn't pretty, it does accurately reflect the views of
the authors.

The best way to predict the future is to create it.  - Alan Kay

Privacy matters!  We know from recent events that people are using our
services to speak in defiance of unjust governments.   We treat privacy and
security as matters of life and death, because for some users, they are.

On Tue, Aug 5, 2014 at 12:58 PM, Robert Sparks <> wrote:

> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> <>.
> Please resolve these comments along with any other Last Call comments
> you may receive.
> Document: draft-ietf-conex-abstract-mech-12
> Reviewer: Robert Sparks
> Review Date: 5-Aug-2014
> IETF LC End Date: 8-Aug-2014
> IESG Telechat date: Not on an upcoming telechat agenda
> Summary: Ready for publication as Informational
> This document handles a complex description problem in a very accessible
> way.
> Thank you for the effort that has gone into creating it.
> One minor point to double-check:
> This document goes out of its way to push decisions about measuring in
> packets,
> bytes, or other units to the concrete  encoding proposals. RFC6789 was
> explicit
> about conex exposing a metric of congestion-volume measured in bytes.
> RFC6789 was published a couple of years ago - has that part of it become
> stale?
> If so, it would be good for this document to explicitly call that out.
> If not, (most of section 4.6 goes back to -04 which predates RFC6789),
> does this document need to retain the this flexibility in its description?