Re: [conex] Genart LC review: draft-ietf-conex-abstract-mech-12
Robert Sparks <rjsparks@nostrum.com> Tue, 12 August 2014 17:29 UTC
Return-Path: <rjsparks@nostrum.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 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 <rjsparks@nostrum.com>
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 <bob.briscoe@bt.com>
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/conex/M0g-lpyjXL12faUWz2S8SlhMV0c
Cc: "ietf@ietf.org" <ietf@ietf.org>, General Area Review Team <gen-art@ietf.org>, 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: Tue, 12 Aug 2014 17:29:47 -0000
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 > <mailto: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 >> <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 >
- [conex] Genart LC review: draft-ietf-conex-abstra… Robert Sparks
- Re: [conex] Genart LC review: draft-ietf-conex-ab… Matt Mathis
- Re: [conex] Genart LC review: draft-ietf-conex-ab… Bob Briscoe
- Re: [conex] Genart LC review: draft-ietf-conex-ab… John Leslie
- Re: [conex] Genart LC review: draft-ietf-conex-ab… Bob Briscoe
- Re: [conex] Genart LC review: draft-ietf-conex-ab… John Leslie
- Re: [conex] Genart LC review: draft-ietf-conex-ab… Bob Briscoe
- Re: [conex] Genart LC review: draft-ietf-conex-ab… Bob Briscoe
- Re: [conex] Genart LC review: draft-ietf-conex-ab… Robert Sparks
- Re: [conex] Genart LC review: draft-ietf-conex-ab… Matt Mathis
- [conex] Genart telechat review: draft-ietf-conex-… Robert Sparks
- Re: [conex] [Gen-art] Genart telechat review: dra… Jari Arkko