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

[<[e-mail]>]

Hi Roland,

I support your draft and I prefer the DSCP you suggest definitely more than CS1. 
A couple of minor comments is given below.

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…

Regards, Ruediger

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

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

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.

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

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).

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

2.  PHB Description

[RG]  sw /This PHB../ The LE PHB/  twice in this sentence

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.

---------------------------------------------
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.

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

   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/

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

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

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.