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@xxxxxxxxxxx>
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
|