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

[Bob Briscoe <[e-mail]>]

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 
<<mailto:[e-mail]>[e-mail]> 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