Return-Path: X-Original-To: gen-art@ietfa.amsl.com Delivered-To: gen-art@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4A731A040A; Tue, 12 Aug 2014 10:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668] autolearn=ham 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 JPnXJdDj3gYx; Tue, 12 Aug 2014 10:29:40 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00E071A034B; Tue, 12 Aug 2014 10:29:39 -0700 (PDT) Received: from unnumerable.local (pool-173-57-89-168.dllstx.fios.verizon.net [173.57.89.168]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s7CHTUsB002205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK); Tue, 12 Aug 2014 12:29:31 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-89-168.dllstx.fios.verizon.net [173.57.89.168] claimed to be unnumerable.local Message-ID: <53EA4EFA.9040601@nostrum.com> Date: Tue, 12 Aug 2014 12:29:30 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Bob Briscoe References: <201408081317.s78DHX8w006624@bagheera.jungle.bt.co.uk> In-Reply-To: <201408081317.s78DHX8w006624@bagheera.jungle.bt.co.uk> Content-Type: multipart/alternative; boundary="------------060704040000080506080501" Archived-At: http://mailarchive.ietf.org/arch/msg/gen-art/k9u_HxCAJKntM6Xgm3PYBhIdZ5w Cc: "ietf@ietf.org" , Nandita Dukkipati , General Area Review Team , conex@ietf.org, Matt Mathis , draft-ietf-conex-abstract-mech.all@tools.ietf.org, marcelo bagnulo braun Subject: Re: [Gen-art] Genart LC review: draft-ietf-conex-abstract-mech-12 X-BeenThere: gen-art@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GEN-ART: General Area Review Team" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 17:29:47 -0000 This is a multi-part message in MIME format. --------------060704040000080506080501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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 > 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? >> > ________________________________________________________________ > Bob Briscoe, BT > --------------060704040000080506080501 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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>.
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


--------------060704040000080506080501--