Subject: [tsvwg] Benjamin Kaduk's No Objection on draft-ietf-tsvwg-le-phb-09: (with COMMENT)

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 17 Feb 2019 11:24:35 -0800

Benjamin Kaduk has entered the following ballot position for
draft-ietf-tsvwg-le-phb-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-le-phb/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

This document is generally in fine shape, and has some good discussion
in it.  I basically just have some editorial suggestions.

As one general note, the text sometimes seems to present a mixed story,
for example in the case of "downgrading" traffic from other PHBs.  We're
told to in general not do this instead of dropping traffic, but on the
other hand an example use of the LE PHB is for downgrading traffic from
some other PHB (but only when it does not violate the operational
objectives of that other PHB).  Greater clarity on who is authorized to
decide to downgrade, and in what cases it makes sense, could be useful.
In a similar vein, the text sometimes suggests a dichotomy between use
of the LE PHB for "preemptable" traffic vs. as a "scavenger" service
class, and at other times suggests that these usages are identical.  But
those are, of course, editorial matters.

Abstract

                                        The primary objective of this LE
   PHB is to protect best-effort (BE) traffic (packets forwarded with
   the default PHB) from LE traffic in congestion situations, i.e., when
   resources become scarce, best-effort traffic has precedence over LE
   traffic and may preempt it.  Alternatively, packets forwarded by the
   LE PHB can be associated with a scavenger service class, i.e., they
   scavenge otherwise unused resources only.  [...]

It seems like "preemptable" and "scavenger" are being deliberately
conflated, but are not necessarily the same.

Section 3

   (e.g., if a transport connection fails due to timing out, the
   application may try several times to re-establish the transport
   connection in order to resume the application session before finally

There was some directorate review traffic suggesting that further
qualifications about the retries; I do see such qualifying statemnets in
the next paragraph, so maybe there is no big need to do so here as well..

   Use of the LE PHB might assist a network operator in moving certain
   kinds of traffic or users to off-peak times.  Alternatively, or in
   addition, packets can be designated for the LE PHB when the goal is
   to protect all other packet traffic from competition with the LE

Is it "alternatively" or "in addition" -- can it really be both at the
same time?  (I suppose the intent is that different operators could
apply different policies?)

Section 9

Is there a section reference in RFC 3754 to point us to?

(Also, the RFC Editor will probably put a comma after "Basically".)

   Several forwarding error correction coding schemes such as fountain
   codes (e.g., [RFC5053]) allow reliable data delivery even in

I'm used to seeing "forward error correction"; is "forwarding error
correction" also an acceptabale usage?

   While the resource contention problem caused by multicast packet
   replication is also true for other Diffserv PHBs, LE forwarding is
   special, because often it is assumed that LE packets get only

nit: s/get only/only get/

   forwarded in case of available resources at the output ports.  The
   previously mentioned redundancy data traffic could nicely use the
   varying available residual bandwidth being utilized the by LE PHB,
   but only if the previously specific requirements in the internal
   implementation of the network devices are considered.

I'm not sure how to interpret "previously specific requirements", here.
Was it intended to be "previously specified requirements"?

Section 12

As per the GenART review, updating the draft in missref is a bit weird,
but we can probably leave it to the responsible AD and RFC Editor to
decide whether to retain the "Updates" relationship or directly effect
the needed changes.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 19 Feb 2019 05:53:35 -0800

Just following up ...

> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-le-phb/

I do have an RFC Editor Note that points this out, added after the GenART
review. So we should be good to go on that point.

Spencer

---

From: Roland Bless <[email-masked]>
Date: Wed, 20 Feb 2019 23:16:10 +0100

Hi Benjamin,

Ok, I'll re-read the text and try to add a bit of clarifying text.

> those are, of course, editorial matters.

Thanks for pointing that out. I think you are right, but it
is the very nature of the LE: it should scavenge residual capacity,
but it must be preemptable by BE in case it needs more resources,
so it has both facets.

> conflated, but are not necessarily the same.

The scavenger part came in somewhat late and that may have caused
the confusion by the conflation. I'll try to clarify this a bit more.

> the next paragraph, so maybe there is no big need to do so here as well..

Yep.

> apply different policies?)

This formulation is actually taken unchanged from the original RFC 3662,
but I may rephrase it. I think it can be "in addition", because
it may belong to different traffic aggregates. The background of this
stems IMHO from the fact that in former times, some operators throttled
or blocked peer-to-peer file sharing traffic. A better option would be
to let users mark it as LE and simply accept it, because it does no
harm to other traffic.

> Is there a section reference in RFC 3754 to point us to?

I don't think so, because the whole RFC discusses Multicast and Diffserv.

> (Also, the RFC Editor will probably put a comma after "Basically".)

Done. :-)

> correction" also an acceptabale usage?

Good catch, will use Forward Error Correction.

> nit: s/get only/only get/

Done.

> Was it intended to be "previously specified requirements"?

Ok, then I need to state that more explicitly: it refers to the
replication condition in the preceding paragraph.

> decide whether to retain the "Updates" relationship or directly effect

Spencer already replied to this.

Best regards,
 Roland

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 20 Feb 2019 16:23:59 -0600

Hi Roland,

Thanks for the updates and the offer to reread with clarifications in
mind.  Just one more note, inline...

> replication condition in the preceding paragraph.

It sounds like we want the "specific requiremnets stated above", t hen.

-Benjamin