Subject: [PCN] Should interior Diffserv nodes remark the DSCP?

From: Bob Briscoe <[email-masked]>
Date: Tue, 18 Mar 2008 17:11:01 +0000

Lars,

I have never liked the idea of using multiple DSCPs for different 
congestion markings but the same scheduling PHB... But constraints I 
recently identified on use of the ECN field through tunnels (see 
posting a week ago) force us to switch DSCPs if we want more than one 
level of congestion marking - unless we get the tunnelling behaviour changed.

You've also been advising against interior nodes switching DSCPs for 
congestion marking if at all possible, saying this may not be 
disallowed by the DS specs, but it is certainly not common practice.

So, before embarking on an experiment where we use at least two DSCPs 
for PCN marking, I have been checking what the DS specs say. All the 
relevant quotes I've found so far are pasted at the end.

Summary of my interpretation:
Re-marking DSCPs for congestion marking on interior nodes is a way of 
using DSCPs to indicate a change in network state, which is 
explicitly envisaged by the Diffserv architecture [RFC2475]. 
Re-marking DSCPs at interior nodes to demote traffic to a 'lower' PHB 
is also envisaged [RFC2474]. So everyone has to assume that interior 
nodes might re-mark DSCPs. However, there are other cases, even in 
IETF RFCs, where it is assumed that interior nodes will not re-mark 
DSCPs. In summary, pre-congestion is a perfectly legitimate reason 
for interior nodes to re-mark DSCPs, but we should expect possible 
feature interactions with other stuff, even though that other stuff 
shouldn't assume DSCPs are immutable.

Bob

===============================================================================
RFC2474 (Stds track) DS Field
--------------------
3.  Differentiated Services Field Definition
    ...                                       Operators may choose to use
    different codepoints for a PHB, either in addition to or in place of
    the recommended default.  Note that if operators do so choose, re-
    marking of DS fields may be necessary at administrative boundaries
    even if the same PHBs are implemented on both sides of the boundary.
    ...
{This sentence implies multiple DSCPs may map to the same PHB.}

5.  Per-Hop Behavior Standardization Guidelines
    ...                 A PHB group specification SHOULD describe
    conditions under which a packet might be re-marked to select another
    PHB within the group.  It is RECOMMENDED that PHB implementations do
    not introduce any packet re-ordering within a microflow.  PHB group
    specifications MUST identify any possible packet re-ordering
    implications which may occur for each individual PHB, and which may
    occur if different packets within a microflow are marked for
    different PHBs within the group.
    ...
{A PHB group specification is the behaviour of an interior node, so 
this sentence shows that interior node remarking is expected. 
However, only remarking to another PHB is mentioned. Remarking to 
another DSCP within the same PHB is neither mentioned nor precluded.}

RFC2475 (Informational) DS Architecture
-------
2.  Differentiated Services Architectural Model

    ...                             Each behavior aggregate is identified
    by a single DS codepoint.
    ...{Contradicts S.3 of RFC2474 above}

2.1.1  DS Boundary Nodes and Interior Nodes

    Interior nodes may be able to perform limited traffic conditioning
    functions such as DS codepoint re-marking.
{Clear-cut evidence that interior DSCP re-marking is expected.}

2.4  Per-Hop Behaviors
    ...                     A codepoint->PHB mapping table may contain
    both 1->1 and N->1 mappings.
    ...

3.  Per-Hop Behavior Specification Guidelines
    ...
    G.6:  It may be possible or appropriate for a packet marked for a PHB
    within a PHB group to be re-marked to select another PHB within the
    group; either within a domain or across a domain boundary.  Typically
    there are three reasons for such PHB modification:

    a. The codepoints associated with the PHB group are collectively
       intended to carry state about the network,
    b. ...
    ...
    A PHB specification should clearly state the circumstances under
    which packets marked for a PHB within a PHB group may, or should be
    modified (e.g., promoted or demoted) to another PHB within the group.
    If it is undesirable for a packet's PHB to be modified, the
    specification should clearly state the consequent risks when the PHB
    is modified.   A possible risk to changing a packet's PHB, either
    within or outside a PHB group, is a higher probability of packet re-
    ordering within a microflow.  PHBs within a group may carry some
    host-to-host, WAN edge-to-WAN edge, and/or domain edge-to-domain edge
    semantics which may be difficult to duplicate if packets are re-
    marked to select another PHB from the group (or otherwise).

    For certain PHB groups, it may be appropriate to reflect a state
    change in the node by re-marking packets to specify another PHB from
    within the group.  If a PHB group is designed to reflect the state of
    a network, the PHB definition must adequately describe the
    relationship between the PHBs and the states they reflect.  Further,
    if these PHBs limit the forwarding actions a node can perform in some
    way, these constraints may be specified as actions the node should,
    or must perform.
{The ability to reflect a state change in an interior node by 
re-marking is precisely what PCN is doing - to notify a change in 
state from not pre-congested to pre-congested, and back again.}

RFC2597 (Standards Track) AF PHB Group
-------
{No mention of interior node re-marking of DSCPs}

RFC3086 (Informational) Specification of PDBs
-------

4.1.2 Crossing the DS domain: transit effects
    ...
    DSCPs should not change in the interior of a DS domain as there is no
    traffic conditioning being applied.  If it is necessary to reapply
    the kind of traffic conditioning that could result in remarking,
    there should be a DS domain boundary at that point, though such an
    "interior" boundary can have "lighter weight" rules in its TCA.
    Thus, when measuring attributes between locations as indicated in
    figure 3, the DSCP at the egress side can be assumed to have held
    throughout the domain.
    ...{This implies there is an assumption that DSCPs don't change 
across a domain, contradicting RFC2474 & RFC2475 above.}

Hope this helps

Bob

____________________________________________________________________________
Bob Briscoe, <[email-masked]>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196 

_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn