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

Matt Mathis <mattmathis@google.com> Fri, 24 October 2014 20:35 UTC

Return-Path: <mattmathis@google.com>
X-Original-To: conex@ietfa.amsl.com
Delivered-To: conex@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39C4A1A70E2 for <conex@ietfa.amsl.com>; Fri, 24 Oct 2014 13:35:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level:
X-Spam-Status: No, score=-1.388 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2-gUGb0LNux for <conex@ietfa.amsl.com>; Fri, 24 Oct 2014 13:35:35 -0700 (PDT)
Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 582791A6F64 for <conex@ietf.org>; Fri, 24 Oct 2014 13:35:35 -0700 (PDT)
Received: by mail-ob0-f169.google.com with SMTP id va2so931898obc.14 for <conex@ietf.org>; Fri, 24 Oct 2014 13:35:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=t5Zt8G10aTs3GQ2hrot29vtQ0we4Vy7gbH2ZzSVPcW4=; b=GAYy/IWAsq+ENiCNgM6ms4eYzPiomOiGyTZ6Opo/xnYitVBY+40dTGHBAs6i+nSF2t CTL5OSbCtV02JdZVZYv5byWubumXAR+rGd8v9yzvm3pqPH1rSm9qSXy61S4OBdrwyNcE 23pLtvmeXPNgLPoazSd5jCLDYukw5RTOwwGDdozOMW1nMXXbNzx+aY/wpQaEqF+U8eZa 0OBmBIeEZysD/hT642joDcOl3XTLmhn7ILyqHmqXLeyQa+txQJ678l3glpah3HnNxDKg +SpNkkn+F4rajDaeQXT2jeEBUvtpQ9zASkQadYtDpy2EzOfIsDXko2aI1QK0QF6Ama9I P6xA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=t5Zt8G10aTs3GQ2hrot29vtQ0we4Vy7gbH2ZzSVPcW4=; b=HMlY1G+9w959JMWENs11ToA1AgEcqRkKE+tgIwSuA2DAokuMKJbdnfwUwHTrVCJiqA 9xdBWBAGrY7ut9KYYKqqAQixHmwe6UbBXgTR5kZBICwJBSrfLuKlOZerzQvB9hE4SdNB 8HkNPlfxdnawXD7qprrogYFlsTGpzLhYW3rmqgfSVpnPFuIfYAsMzjWSGNX/GFAJZOtB uOBOrkRBH5pLt3U5i508pW0Zeo9Wx2ZFVdb69t6NKjeqwlq7ovytY+122yyZGaRDAlV4 +8+ZB4B/539UwNBbqsyfB5ZFcj1+oXYTIRCwTOi6Z+bdm3uYL/1i/kZu2I41Y29XezX3 LM7g==
X-Gm-Message-State: ALoCoQlknBgV2gfc7L+V94esS4h8qiBQ/C5Z5NnoyEuSpoQtcEUlURdcnNLGZ0LS9Y8jqdeZsU8g
MIME-Version: 1.0
X-Received: by 10.202.193.138 with SMTP id r132mr3682253oif.52.1414182934597; Fri, 24 Oct 2014 13:35:34 -0700 (PDT)
Received: by 10.182.139.69 with HTTP; Fri, 24 Oct 2014 13:35:34 -0700 (PDT)
In-Reply-To: <53EA4EFA.9040601@nostrum.com>
References: <201408081317.s78DHX8w006624@bagheera.jungle.bt.co.uk> <53EA4EFA.9040601@nostrum.com>
Date: Fri, 24 Oct 2014 16:35:34 -0400
Message-ID: <CAH56bmBPGnfCumgX31RpUSKbWVyaocp+ejsy12vp9bqJb2J0VQ@mail.gmail.com>
From: Matt Mathis <mattmathis@google.com>
To: Robert Sparks <rjsparks@nostrum.com>
Content-Type: multipart/alternative; boundary=001a113dc36876fe050506311f82
Archived-At: http://mailarchive.ietf.org/arch/msg/conex/Y81uBknD9vPZ0A-ftx-cKvsVpaA
Cc: "ietf@ietf.org" <ietf@ietf.org>, General Area Review Team <gen-art@ietf.org>, ConEx IETF list <conex@ietf.org>, draft-ietf-conex-abstract-mech.all@tools.ietf.org
Subject: Re: [conex] Genart LC review: draft-ietf-conex-abstract-mech-12
X-BeenThere: conex@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Congestion Exposure working group discussion list <conex.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/conex>, <mailto:conex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/conex/>
List-Post: <mailto:conex@ietf.org>
List-Help: <mailto:conex-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/conex>, <mailto:conex-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Oct 2014 20:35:38 -0000

I made one tweak relative to this change as previously agreed: the very
last paragraph of the original section was not marked to be deleted but had
been pulled up earlier in the section.  I deleted the duplicate text.

I also changed one word in the abstract, per another LC suggestion and
discussion with Bob.

Thanks,
--MM--
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 12, 2014 at 1:29 PM, Robert Sparks <rjsparks@nostrum.com> wrote:

>  This text would work for me.
> The chairs and AD should verify it reflects consensus.
>
> Thanks!
>
> RjS
>
>
> On 8/8/14, 8:17 AM, Bob Briscoe wrote:
>
> Robert,
>
> We're glad you found it accessible. Thank you for pointing out the
> inconsistency between this, 7141 & 6789 - I (Bob) am impressed given I was
> a co-author of all of them and I hadn't noticed. We have suggested edits
> below to remove the inconsistency, moving up the last para and adding some
> explanatory text (unlike the original text, it is not indented).
>
> Ideally, RFC6789 should have said that its definition of congestion-volume
> is applicable to today's Internet and may change. Given most RFCs only
> apply to today's Internet, we don't think we need to go to the trouble of
> updating 6789. So, instead, we have qualified the applicability of 6789 in
> this document.
>
> =======================================================================
> CURRENT:
>    Whether to use bytes or packets is not obvious.  For instance, the
>    most expensive links in the Internet, in terms of cost per bit, are
>    all at lower data rates, where transmission times are large and
>    packet sizes are important.  In order for a policy to consider wire
>    time, it needs to know the number of congested bytes.  However, high
>    speed networking equipment and the transport protocols themselves
>    sometimes gauge resource consumption and congestion in terms of
>    packets.
>
>    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).  It may help to refer to the guidance in [RFC7141].
>
>    [RFC7141] advises that congestion indications should be interpreted
>    in units of bytes when responding to congestion, at least on today's
>    Internet.  In any TCP implementation this is simple to achieve for
>    varying size packets, given TCP SACK tracks losses in bytes.  If an
>    encoding is specified in units of bytes, the encoding should also
>    specify which headers to include in the size of a packet (see network
>    layer requirement F in Section 3.3).
> SUGGESTED:
>    Whether to use bytes or packets is not obvious.  For instance, the
>    most expensive links in the Internet, in terms of cost per bit, are
>    all at lower data rates, where transmission times are large and
>    packet sizes are important.  In order for a policy to consider wire
>    time, it needs to know the number of congested bytes.  However, high
>    speed networking equipment and the transport protocols themselves
>    sometimes gauge resource consumption and congestion in terms of
>    packets.
>
>    [RFC7141] advises that congestion indications should be interpreted
>    in units of bytes when responding to congestion, at least on today's
>    Internet.  [RFC6789] takes the same view in its definition of
> congestion-volume, again for today's Internet.
>
>    In any TCP implementation this is simple to achieve for
>    varying size packets, given TCP SACK tracks losses in bytes.  If an
>    encoding is specified in units of bytes, the encoding should also
>    specify which headers to include in the size of a packet (see network
>    layer requirement F in Section 3.3).
>
> RFC 7141 constructs an argument for why equipment tends to be built so
> that the bottleneck will be the bit-carrying capacity of its interfaces not
> its packet processing capacity. However, RFC 7141 acknowledges that the
> position may change in future, and notes that new techniques will need to
> be developed to distinguish packet- and bit-congestion.
>
> Given this document describes an abstract ConEx mechanism, it is intended
> to be timeless. Therefore it 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).  It may help to refer to the guidance in [RFC7141].
> =======================================================================
>
> Regards
>
>
> Bob Briscoe & Matt Mathis
>
>
> On Wed, Aug 6, 2014 at 1:28 AM, Robert Sparks <rjsparks@nostrum.com>
> wrote:
>
>  I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART,
> please see the FAQ at
>  < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>gt;.
>  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?
>
>  ________________________________________________________________
> Bob Briscoe,                                                  BT
>
>
>