Re: [tsvwg] I-D Action: draft-tsvwg-le-phb-00.txt

["Bless, Roland (TM)" <[e-mail]>]

Hi Rüdiger,

thanks for the comments. I just submitted a new version of the
draft and tried to incorporate most of your comments. Comments inline.

Am 02.12.2016 um 13:30 schrieb [e-mail]:

> I observe that the text as is contains two “SHOULD”. I think to 
> recall statements of either WG chairs or ADs that a low number of
> “SHOULD” and the absence “MUST” standards language is insufficient to
> justify standards track. Maybe David or Gorry could add a statement 
> whether my recollections reflects an individual point of view rather
> than IETF policy.
> 
> This is to say, I RECOMMEND to add some more standards language…

:-) I tried to do that. However, since DiffServ is quite flexibly
defined (w.r.t. internal marking and PHB mapping), I wasn't able to
identify many places for MUSTs.

> -----Comments--------------
> 
> 1.  Introduction
> 
> intended for traffic of sufficiently low urgency
> 
> traffic has got a low priority in time, which does not necessarily 
> imply that it is generally of minor importance
> 
> traffic for which delivery is considered optional.
> 
> 1.1.  Applicability
> 
> for sending extremely non-critical traffic
> 
> [RG] the above definitions of traffic suitable for LE transport may 
> be harmonized. I'm not sure whether 'does not imply minor importance'
>  and 'extremely non-critical' match each other really well. Maybe: 
> The PHB LE is applicable for traffic and applications of a user 
> accepting the presence of severe congestion conditions during any
> time an LE marked IP flow is sent.
> 
> [RG] See also RFC 4594 (whose definition may be an option here too):
>  Low-Priority Data for applications or services that can tolerate 
> short or long interruptions of packet flows.  The Low-Priority Data
> service class can be viewed as "don't care" to some degree

I tried to harmonize this now, please check the new version.

> -----------------------
> 
> OLD: This is a PHB that allows networks to protect themselves from 
> selected types of traffic rather than giving a selected traffic 
> aggregate preferential treatment.  Moreover, it may also exploit all 
> unused resources from other PHBs NEW: 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
> 
> [RG] I'd suggest to explicitly mention LE in that section.

Done.

> ------------------------------
> 
> 1.2.  Deployment Considerations
> 
> No harm to other traffic: since the LE PHB has got the lowest 
> priority it does not take resources from other PHBs.  Deployment 
> across different provider domains causes no trust issues or attack 
> vectors to existing traffic. o  No parameters or configuration: the
> LE PHB requires no parameters and no configuration of traffic
> profiles and so on.
> 
> [RG] Please state whether this a deployment example. This should
> clarify whether the described deployment is intended to be normative
> (is a 'lowest priority [queue]' the only way to deploy the LE PHB? I
> don't think so).

Tried to make this more clear in the section.

> -------------------
> 
> 2.  PHB Description
> 
> [RG]  sw /This PHB../ The LE PHB/  twice in this sentence

Done.

> A packet forwarded with this PHB SHOULD have lower precedence than 
> packets forwarded with the default PHB.  Ideally, LE packets should 
> be forwarded only if no best-effort packet is waiting for its 
> transmission.  A straightforward implementation could be a simple 
> priority scheduler serving the default PHB queue with higher
> priority than the lower-effort PHB queue.  Alternative
> implementations may use scheduling algorithms that assign a very
> small weight to the LE class.  This, however, may sometimes cause
> better service for LE packets compared to BE packets in cases when
> the BE share is fully utilized and the LE share not.
> 
> [RG] I'm not sure, whether (precedence? applies (but I'm not a native
> speaker). May be a generic description of the properties should be
> added or replace this section: In the case of congestion, LE marked
> traffic SHOULD (MUST?) be dropped prior to dropping any default PHB
> traffic (my take). This leaves space for queuing LE traffic, if
> desired. If the statement is should be dropped immediately in case of
> congestion of the default PHB (i.e. no queuing), I'm fine with that
> too.
> 
> [RG] Related to the original text, please note that the BE traffic
> will consume any spare LE bandwidth. During congestion, both will
> compete for spare bandwidth of other classes by their weight and will
> consume their minimum guaranteed bandwidth. Your original text
> doesn't mention congestion as a pre-condition for LE traffic getting
> better performance than BE traffic.

Tried to incorporate these comments.

> --------------------------------------------- 3.  Traffic
> Conditioning Actions As for most other PHBs an initial classification
> and marking would usually be performed at the first DS boundary node.
> In many cases, packets may also be pre-marked in DS aware end systems
> by applications due to their specific knowledge about the particular 
> precedence of packets.  There is no incentive for DS domains to 
> distrust this initial marking, because letting LE traffic enter a DS 
> domain causes no harm.
> 
> [RG] I'd prefer the conditioning section to express a requirement of
> explicit user consent to LE transport in any part of his
> communication. Maybe: - SHOULD be pre-marked as LE by DS aware user
> terminals originating traffic - MAY be classified an marked LE by
> User managed devices within the user domain - Default PHB traffic
> MUST NOT be classified and remarked to LE by a DS boundary node which
> isn't managed by a user.

I used the alternative phrases:
   If possible, packets SHOULD be pre-marked in DS-aware end systems by
   applications due to their specific knowledge about the particular
   precedence of packets.

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


> -------------------
> 
> Usually, the amount of LE traffic is implicitly limited by queueing 
> mechanisms and related discard actions of the PHB.  Therefore, there 
> is normally no need to meter and police LE traffic explicitly.
> 
> [RG] sw /queueing/queuing/

Not sure, RFC2474 also uses queueing. RFC editor will let me know :-)

> [RG] LE traffic MUST NOT be metered and SHOULD NOT be policed?

I think this statement would be too strong. Assume that someone wants to
forward LE, but hasn't got any LE queue left, so it must be
mapped to the BE PHB. I order to make sure that it doesn't
adversely affect the BE aggregate, one could use a token
bucket policer at the ingress to limit the LE bandwidth.
I don't want to preclude that, though the disadvantage
compared to the queue solution it quite obvious.

> --------------------------
> 
> 4.  Recommended DS Codepoint
> 
> [RG] sw /The recommended/The RECOMMENDED/
> 
> RFC 4594 [RFC4594] recommended to use CS1 as codepoint (as mentioned 
> in [RFC3662].
> 
> [RG] RFC4594 in a way also adds information related to LE marking if
> a domain doesn’t support LE. I’d suggest to add a Diffserv-intercon 
> discussion here. Suggested text:
> 
> [RG] It is further suggested that a sending domain internally marking
> LE traffic by CS1 remarks traffic by the LE DSCP 000 010 recommended
> above, if it is forwarded to a domain applying Diffserv-intercon and
> its treatment of CS1 marked traffic is unknown. This raises the
> probability that the DSCP is preserved end-to-end, whereas as CS1
> marked packet may be remarked by the default DSCP by the receiving
> domain.
> 
> [RG] Extract of RFC 4594: In network segments that use IP precedence
> marking, only one of the two service classes can be supported,
> High-Throughput Data or Low-Priority Data.  We RECOMMEND that the
> DSCP value(s) of the unsupported service class be changed to 000xx1
> on ingress and changed back to original value(s) on egress of the
> network segment that uses precedence marking.  For example, if
> Low-Priority Data is mapped to Standard service class, then 000001
> DSCP marking MAY be used to distinguish it from Standard marked
> packets on egress.

Thanks for pointing that out. I now added the following text:
   o  [RFC4594] recommended to remark Low-Priority Data to DSCP '000001'
      inside a DS domain that uses IP precedence marking.  By using the
      herein defined LE DSCP such remarking is not necessary, so even if
      Low-Priority Data is unsupported (i.e., mapped to the default PHB)
      the LE DSCP should be kept across the domain as RECOMMENDED in
      Section 5.

Regards,
 Roland