Subject: [tsvwg] LE PHB -01 draft comments (from David Black)

From: "Black, David" <[email-masked]>
Date: Fri, 3 Mar 2017 23:59:13 +0000

Roland,

<WG chair hat OFF>

I'm writing this email as the draft shepherd, not WG chair.

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

First of all, thanks for working on this draft to help clean up a long-standing set of problems around Lower Effort traffic marking and handling.  I've done a relatively thorough review of this draft, and listed comments in order of occurrence.   Technical issues that need some attention are noted with ** for minor issue and **** for major issues, and summarized here:

** Section 1.2 - I wonder whether the 2nd and 3rd bullets are overstated.

**** Section 3 - First paragraph needs some attention as it seems to switch back and forth between networks in general and networks with full support for LE

**** Section 5 - "MUST remark" requirement, is not backwards compatible with RFC 4594, needs WG discussion

** Section 7 - IANA Considerations need some attention

** Section 8 - Mention of traffic "downgraded" to LE seems to conflict with recommendations not to downgrade to LE elsewhere.

I also generally concur with Ruediger's comments, and in particular share his concern about whether "precedence" is the right word here - that might be good to discuss in Chicago.

-- Section 1

OLD
   sufficiently low urgency, in which all other traffic takes precedence
NEW
   sufficiently low urgency that all other traffic takes precedence

Editorial

   Low
   urgency traffic has got a low priority in time, which does not
   necessarily imply that it is generally of minor importance.

"has got a low priority in time" -> "has a low priority for timely forwarding"

OLD
   Alternatively, the effect of this type of traffic on all other
   network traffic is strictly limited.
NEW
   Other networks may strictly limit the effects of this type of
   traffic on all other network traffic.

(This is to parallel wording at start of immediately previous paragraph)

-- Section 1.1

OLD
   A Lower Effort PHB is applicable for most elastic applications that
   otherwise use best-effort delivery.  More specifically, it is
   suitable for traffic and services accepting strongly varying
   throughput for their data flows, especially with respect to periods
   of very low throughput or even starvation (i.e., long interruptions
   due to excessive packet loss).
NEW
   A Lower Effort PHB is applicable for many applications that
   otherwise use best-effort delivery.  More specifically, it is
   suitable for traffic and services that can tolerate strongly
   varying throughput for their data flows, especially periods
   of very low throughput or even starvation (i.e., long interruptions
   due to significant or even complete packet loss).

Minor edits - "most" seems overstated in first sentence.

OLD
   nor should packets be "downgraded" to the LE PHB used as a
   substitute for dropping packets that ought simply to be dropped as
   unauthorized.
NEW
   nor should packets be "downgraded" to the LE PHB instead of being
   dropped, particularly when the packets are unauthorized traffic.

Editorial

   The LE PHB is expected to have applicability in
   networks that have at least some unused capacity at some times of
   day.

Just times of day, or also days of the week, holidays, etc.?   I suggest generalizing this text.

OLD
   The LE PHB allows networks to protect themselves from selected types
   of traffic rather than giving a selected traffic aggregate
   preferential treatment.  Moreover, the LE PHB may also exploit all
   unused resources from other PHBs.
NEW
   The LE PHB allows networks to protect themselves from selected types
   of traffic as a complement to giving preferential treatment to other
   selected traffic aggregates.  Moreover, the LE PHB may take advantage
   of network resources unused by other PHBs.

Editorial

OLD
   There is no intrinsic reason to limit the applicability of the LE PHB
   to any particular application or type of traffic.  It is intended as
   an additional tool for administrators in engineering networks.  For
   instance, it can be used for filling up protection capacity of
   transmission links which is otherwise unused.  Some network providers
   keep link utilization below 50% in order to being able carrying all
   traffic without loss in case of rerouting due to a link failure.
NEW
   There is no intrinsic reason to limit the applicability of the LE PHB
   to any particular application or type of traffic.  It is intended as
   an additional traffic engineering tool for network administrators.
  For instance, it can be used to fill protection capacity of
   transmission links that is otherwise unused.  Some network providers
   keep link utilization below 50% to ensure that all traffic without
   loss after rerouting caused by a link failure.

"engineering" -> "traffic engineering" is important, all other changes are editorial.

  Example uses for the LE PHB comprise:

Delete "comprise"

** The last bullet in Section 1.1. contains some discussion of "downgraded" that goes beyond an example, and ought to be merged into the last paragraph on p.3.

-- Section 1.2

First bullet: "has got" -> "has"

** I wonder whether the 2nd and 3rd bullets are overstated.  There is some network switch/router configuration required and something like a low priority queue has to be set up to drop LE traffic when there are other competing uses.   I don't think the bullets are actually wrong, but some additional text to point out what does have to be done to use the LE PHB would be helpful.

-- Section 2

OLD
  Ideally, LE packets SHOULD be forwarded only if no best-
   effort packet is waiting for its transmission.
NEW
   Ideally, LE packets SHOULD be forwarded only if no packet
   with any other PHB is awaiting transmission.

Understated - should apply to all PHBs, not just default.

-- Section 3

**** First paragraph needs some attention as it seems to switch back and forth between networks in general (LE causes effects that are best-effort at worst) and networks with full support for LE (last sentence recommending no boundary policing assumes that LE is preferentially dropped wrt all other PHBs at all bottlenecks).  At a  minimum, a network that forwards LE as Default, needs to treat LE traffic as part of a Traffic Aggregate that is at least LE + Default and police that appropriately at the edge.   In general, I suggest thinking carefully about separating statements that apply to all networks (with and degree or absence of LE PHB support) from those that apply to networks with full LE support at every possible bottleneck (warning: this can be subtle, e.g.,  there may be an L2 link bottleneck that doesn't understand the LE vs. Default distinction for IP traffic).

   Non-LE traffic (e.g., BE traffic) SHOULD not be remarked to LE on a
   regular basis without consent or knowledge of the user.

"SHOULD not" -> SHOULD NOT"

Also, this text  feels like it's part of the "downgrade" discussion at the end of p.3, and at least ought to point back to that.

--Section 5

   A DS domain that still uses DSCP CS1 for marking LE traffic
   (including Low Priority-Data as defined in [RFC4594<https://tools.ietf.org/html/rfc4594>] or the old
   definition in [RFC3662<https://tools.ietf.org/html/rfc3662>]) MUST remark traffic to the LE DSCP '000010'
   at the egress to the next DS domain.

****I definitely want to see broader WG discussion of that "MUST remark" requirement, as it's not backwards compatible with RFC 4594 - at a minimum, some thought should be applied to transition and mixing networks that use CS1 and the new LE DSCP.

--Section 7

** (entire set of comments on Section 7)

IANA Considerations need to tell IANA what Name to use for the codepoint (LE) and what to use as a Reference (this document).    In general, when assigning a field from an existing registry, check the columns that IANA will need to fill in and supply contents.

This section will need some editing, as the "Standards Action" of this memo is what assigns that codepoint.  Suggestion:

   This document assigns the Differentiated Services  Field Codepoint (DSCP)

   '000010' from the Differentiated Services  Field Codepoints (DSCP) registry

   (https://www.iana.org/assignments/dscp-registry/dscp-registry.xml) to the

   LE PHB.  IANA is requested to update the registry as follows:

                - Name: LE

                - Codepoint: 000010

                - Reference: [RFC number of this memo]

Also, I just notice that the header on the middle column of the IANA registry is "Space" - it should be "Codepoint":

   IANA is also requested to correct the header of the middle column

   of the Pool 1  Codepoints table in that registry by changing it from

   "Space" to "Codepoint".

-- Section 8

** Mention of traffic "downgraded" to LE seems to conflict with recommendations not to downgrade elsewhere.

</WG chair hat OFF>

Thanks, --David

--------------------------------------------------------

David L. Black, Distinguished Engineer

Dell EMC, 176 South St., Hopkinton, MA  01748

+1 (508) 293-7953     Cell: +1 (978) 394-7754

[email-masked]  <=== NEW ===

--------------------------------------------------------

---

From: <[email-masked]>
Date: Wed, 22 Mar 2017 09:51:22 +0000

Hallo Roland,

the draft reads better now. David commented version 01 and I'd like to pick up some of his content related comments (marked [DB]) and add some own ones (marked [RG]).

Regards, Ruediger

-- Section 1

[DB] The last bullet in Section 1.1. contains some discussion of "downgraded" 
that goes beyond an example, and ought to be merged into the last paragraph 
on p.3.

[RG] I share David's point of view.

-- Section 1.2

[RG]
OLD:
      No harm to other traffic: since the LE PHB has got the lowest
      forwarding priority it does not consume resources from other PHBs.
      Deployment across different provider domains causes no trust
      issues or attack vectors to existing traffic.

NEW
      No harm to traffic of other PHBs: since packets marked for LE PHB 
      are dropped prior to packets of any other PHB, they don't consume 
      resources required by other PHBs. Deployment across different 
      provider domains causes no trust issues or attack vectors to 
      traffic of other PHBs.
-----------------------
[DB] I wonder whether the 2nd and 3rd bullets are overstated.  There is some 
network switch/router configuration required and something like a low priority 
queue has to be set up to drop LE traffic when there are other competing uses.   
I don't think the bullets are actually wrong, but some additional text to point 
out what does have to be done to use the LE PHB would be helpful.

[RG] I share David's point of view.

-- Section 2
[DB]
OLD

[DB] Understated - should apply to all PHBs, not just default.

[RG] Agree with David.
----------
[RG] There are more options to produce LE: a router may offer 
a committed/excess traffic configuration. committed rate/weight 
could be 0 for LE, only an excess rate/weight may be configured. 
If the default PHB has a committed rate above 0 and the default 
PHB excess weight is bigger than LE, LE shouldn't be able to 
seize capacity from default PHB.
If RED is deployed, Default PHB and LE may be produced using 
the same queue. All LE traffic should be dropped by RED prior 
to the first Default PHB packet.

--Section 5

[RG] I wonder, whether ECN related aspects should be discussed:
- should any LE traffic be dropped prior to ECN marks for any 
  other PHB? I think, that is true if ECN is used to indicate 
  congestion.
- should LE be able to support ECN? Or are LE packet drops the 
  only reaction in the case of congestion.

-- Section 8

[RG] Unauthorised marking of traffic as LE may be regarded as 
a kind of denial of service. 
On the other hand, may re-marking traffic which is assumed to 
be dDoS traffic as LE be an alternative to dropping this 
traffic (I can't judge that, may be in some special cases?).