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

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(_at_)nostrum(_dot_)com 
> <mailto:rjsparks(_at_)nostrum(_dot_)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