Skip to main content

A Lower-Effort Per-Hop Behavior (LE PHB) for Differentiated Services
draft-ietf-tsvwg-le-phb-10

Yes

(Spencer Dawkins)

No Objection

(Alvaro Retana)
(Ignas Bagdonas)
(Martin Vigoureux)

Note: This ballot was opened for revision 09 and is now closed.

Warren Kumari
(was Discuss) No Objection
Comment (2019-02-20 for -09) Sent
--- Original DISCUSS position for hysterical raisins --- 
I believe that this should be trivial DISCUSS to address, but I thought it important enough to warrant it. I'm OK with basically whatever you answer, I just wanted to make sure this had been seen and considered.

"An LE PHB SHOULD NOT be used for a customer’s "normal Internet"
   traffic nor should packets be "downgraded" to the LE PHB instead of
   being dropped, particularly when the packets are unauthorized
   traffic.  "

Great, sounds good to me -- but in the USA at least, there is are many cell phone plans which are "unlimited", but after some amount of traffic (e.g 22GB) your connection gets throttled to a lower data rate. Is this traffic still 'a customer's "normal Internet" traffic"? Is it appropriate (whatever that means) to downgrade this traffic to the LE PHB?
I understand not wanting to touch this issue with  a 10 foot pole (and I don't know what the right answer is!), but you *did* open this can of worms by talking about what classification user traffic should have.

Note: I'm happy to clear my DISCUSS no matter what the answer is, I just want to make sure it has been considered / discussed.

---------

Major:
"Some network providers keep link utilization below 50% to ensure that all traffic is forwarded without loss after rerouting caused by a link failure (cf.Section 6 of [RFC3439]).  LE marked traffic can utilize the normally unused capacity and will be preempted automatically in case of link failure when 100% of the link capacity is required for all other traffic. "
Yup - very true. But I think it needs to be mentioned that the provider will need to upgrade their monitoring / management system so that they can see the traffic lass. If they monitoring circuit utilization using e.g interface counters (and not by traffic class), a link may have 1% "real" traffic and 90% LE traffic, and it will look like it it 91% "full". I don't have any suggested text to address this (and this is just a comment, so "well, duh, they should know that anyway!" is a fine answer.)


Nits:
"A main problem is that multicast" -- I'm not sure you can say "A main" - main implies singular.; I'd suggest "The main" or "A major".

"However,using the Lower Effort PHB for multicast requires to pay special" -- "requires paying"...
Mirja Kühlewind Former IESG member
Yes
Yes (2019-02-21 for -09) Sent
Thanks for addressing the TSV-ART comments (and thanks Olivier for the review)!

Two mostly editorial comments from my side:

1) In sec 3: "nor should packets be "downgraded" to the LE PHB  instead of being dropped"
I would suggest to use proper normative language here, e.g. "and packets SHOULD NOT be "downgraded" to the LE PHB instead of being dropped".

2) I would recommend to add a reference to rfc8087 at the end of section 4.
Spencer Dawkins Former IESG member
Yes
Yes (for -09) Unknown

                            
Alexey Melnikov Former IESG member
No Objection
No Objection (2019-02-20 for -09) Sent
Thank you for a well written document.

I only have one nit about the document title:

  A Lower Effort Per-Hop Behavior (LE PHB)

Please use a better title that makes it clearer to readers what are you talking about. Looking at RFC 3662 I see:

  A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services

I think the part "for Differentiated Services" would be very helpful.
Alissa Cooper Former IESG member
No Objection
No Objection (2019-02-20 for -09) Sent
= Section 3 =

"An LE PHB SHOULD NOT be used for a customer's "normal Internet"
   traffic nor should packets be "downgraded" to the LE PHB instead of
   being dropped, particularly when the packets are unauthorized
   traffic."

I would recommend against mixing normative and non-normative keywords for a sequence of behaviors listed in the same sentence. I can't determine why one of these is normative and the other not.

"There is no intrinsic reason to limit the applicability of the LE PHB
   to any particular application or type of traffic."

I get the idea of not wanting to imply any kind of limitation, but wouldn't use cases of applying this to real-time traffic be pretty rare? That seems like a caveat worth explaining.

= Section 15 =

RFC 8174 should be a normative reference.
Alvaro Retana Former IESG member
No Objection
No Objection (for -09) Not sent

                            
Ben Campbell Former IESG member
(was Discuss) No Objection
No Objection (2019-02-20 for -09) Sent
Thank you for addressing my DISCUSS
Benjamin Kaduk Former IESG member
No Objection
No Objection (2019-02-17 for -09) Sent
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.
Deborah Brungard Former IESG member
No Objection
No Objection (2019-02-20 for -09) Sent
I think Warren hit on my concern. There seems to be mixed concepts regarding
how the markings are done. E.g.:
"However, non-LE traffic (e.g., BE traffic) SHOULD NOT be
remarked to LE on a regular basis without consent or knowledge of the user."

Maybe for some users, an operator informs the "user" how their traffic is
marked, but I think it is more of a service contract, doesn't spell out this
detail. Especially if multi-domain. And traffic can be re-marked
(RFC7657/section 3.2). This is really per operator implementation.

Suggest remove this sentence, especially RC2119 language. Agree
also with Warren's examples to fix.
Ignas Bagdonas Former IESG member
No Objection
No Objection (for -09) Not sent

                            
Martin Vigoureux Former IESG member
No Objection
No Objection (for -09) Not sent

                            
Suresh Krishnan Former IESG member
No Objection
No Objection (2019-02-20 for -09) Sent
I was not sure how this behavior in Section 8 is expected to be deployed and used.

"  A DS domain that still uses DSCP CS1 for marking LE traffic
   (including Low Priority-Data as defined in [RFC4594] or the old
   definition in [RFC3662]) SHOULD remark traffic to the LE DSCP
   '000001' at the egress to the next DS domain."

Is the expectation that even on a domain that has not been updated to use the new DSCP there will be some node at the edge that will have been updated? If so, it might be good to explicitly note this. If not, I cannot see how a legacy node will follow this recommendation.