Re: [Detnet] IP Solution problem: Use of DSCP and ECN fields in IP headers for detnet flow identification

["Black, David" <[e-mail]>]

Hi Varga,



I'm pleased that we mostly agree, and I'll be happy to discuss the PHB further.



This discussion may also provide insight into my concern about 5-tuple vs. 6-tuple flow identification - it looks like we have two different sorts of "flow identification" under discussion:

- Identification of a flow in the network in general (network flow or microflow in RFC 2475).

- Identification of a flow that undergoes DetNet processing at a DetNet node (DetNet flow).

At the moment, we're using 5-tuples (src & dst addresses, protocol, src & dst ports) for network flow identification and 6-tuples (5-tuple + DSCP) for Detnet flow identification.  In other words, we're effectively saying that a network flow (defined by a 5-tuple), becomes a DetNet flow when a DetNet DSCP is added to request DetNet forwarding by the network.  There's a level of indirection here caused by the Diffserv architecture - a DetNet DSCP designates a DetNet PHB, and any a packet marked with a DetNet DSCP receives DetNet forwarding at a DetNet node.



That said, my concern is that the 6-tuple term for a DetNet flow seems counter-intuitive to me, even though the DetNet forwarding plane in a DetNet node may well be matching on all 6 elements involved in order to decide whether to provide DetNet forwarding to each arriving packet.



IMHO, a better description would be that a network flow (5-tuple) is being uniformly marked with a DetNet DSCP to request DetNet treatment from the network (and presumably DetNet router hardware is matching on DetNet DSCPs to dispatch inbound packets to DetNet forwarding logic instead of conventional forwarding logic).   The counter-intuitivity of the 6-tuple term arises in the error case when someone uses a "clever" marking of a single 5-tuple flow with a mixture of DetNet and non-DetNet DSCPs.  I believe that the result of that "cleverness" is not multiple flows (which would be implied by the "6-tuple" term), even though it may look like that in a DetNet node implementation.  I think the result is better described as a single not-entirely-DetNet flow (defined by a 5-tuple) that receives bizarre forwarding treatment at DetNet nodes - some of the packets get DetNet forwarding treatment and some get other forwarding treatment, so in a loaded network, significant reordering is likely, and the receiver is probably not going to be happy with the resulting packet arrival order.



If this all makes sense, that "clever" mixing of DetNet and non-DetNet DSCPs in a single flow (hence mixing DetNet and non-DetNet forwarding behavior in a single flow) deserves a "SHOULD NOT" statement in the draft, with a warning about the bizarre forwarding behavior at DetNet nodes that is a likely result, which seems like a better thing to do than my original suggestion for some sort of prohibition on mixing DetNet and non-DetNet packets in the same 5-tuple.



Thanks, --David



From: Balázs Varga A [mailto:[e-mail]]
Sent: Sunday, November 4, 2018 11:13 PM
To: Black, David; [e-mail]
Subject: RE: IP Solution problem: Use of DSCP and ECN fields in IP headers for detnet flow identification



Hi David,



Many thanks for your comments and suggestions. This is definitely something we must fix.

Just two general statement as background:

- ECN was not considered so far to be useful for DetNet flows. DetNet flows expect zero congestion loss.

DetNet sources do not consider to react on ECN.

- Masking for flow identification was considered as a general rule for the "tuples" (i.e. not DSCP specific).



So, regarding your proposals

A, No usage of ECN for flow identification: AGREE

B, DSCP list instead of bitmask: AGREE, it can provide the same result.

C, New DiffServ PHB for DetNet: Agree in principle, let's discuss the details



Thanks

Bala'zs



From: detnet <[e-mail]> On Behalf Of Black, David
Sent: Sunday, November 4, 2018 11:27 PM
To: [e-mail]
Subject: [Detnet] IP Solution problem: Use of DSCP and ECN fields in IP headers for detnet flow identification



We have a problem here ...



The detnet IP solution draft (draft-ietf-detnet-dp-sol-ip-01.txt) has this to say about

use of DSCP and ECN fields in IP headers for detnet flow identification:



6.1.1.4.  IPv4 Type of Service and IPv6 Traffic Class Fields



   These fields are used to support Differentiated Services [RFC2474]

   and Explicit Congestion Notification [RFC3168].  Implementations of

   this document MUST support DetNet flow identification based on the

   IPv4 Type of Service field when processing IPv4 packets, and the IPv6

   Traffic Class Field when processing IPv6 packets.  Implementations

   MUST support bimask based matching, where one (1) values in the

   bitmask indicate which subset of the bits in the field are to be used

   in determining a match.  Note that a zero (0) value as a bitmask

   effectively means that these fields are ignored.



That bitmask approach won't work, as it violates both RFC 2474 and RFC 3168.



Starting with ECN (RFC 3168) - the 2-bit ECN field is intended to enable ECN functionality to be

applied to any flow, and the contents of the ECN field can be changed by any router.  Using ECN

field values to identify separate flows is wrong, see Section 5 of RFC 3168, which specifies the

current use of that field..



That leaves the 6-bit DSCP field, which is defined by RFC 2474.  The above bitmask approach is

prohibited by the following paragraph in section 3 of RFC 2474:



   Implementors should note that the DSCP field is six bits wide.  DS-

   compliant nodes MUST select PHBs by matching against the entire 6-bit

   DSCP field, e.g., by treating the value of the field as a table index

   which is used to select a particular packet handling mechanism which

   has been implemented in that device.  The value of the CU field MUST

   be ignored by PHB selection.  The DSCP field is defined as an

   unstructured field to facilitate the definition of future per-hop

   behaviors.



The CU field is now the ECN field (see RFC 3168).  My reading is that the current section 6.1.1.4 text in

the IP solutions draft has managed to violate all three "MUST" requirements in that RFC 2474

paragraph, which is impressive ... and not in a good way.



I suggest that several things be done:

a)      Abandon use of the ECN field for detnet flow identification.

b)      For the DSCP field, change from a bitmask approach to a list of DSCPs.

a.      I would note that a carefully chosen DSCP list can be implemented via a bitmask.

c)      Define one or more Diffserv PHBs that realize DetNet behavior.

a.      I suspect that much of the content needed for this already exists in the
detnet drafts, so this should not be a "from scratch" exercise.



I would also caution that the current IP solution draft text on 6-tuples for flow identification appears

to allow multiple separate detnet flows that differ only in DSCP to use the same IP 5-tuple (source &

destination addresses, transport protocol, source & destination ports).  I believe that this also ought

to be prohibited, as Diffserv uses 5-tuples for flow identification - see the definition and use of the

term "microflow" in RFC 2475.



A quick glance at the MPLS solution suggests that it does not have an analogous problem with the TC

field in labels as the TC field does not appear to be used for detnet flow identification.



Thanks, --David

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

David L. Black, Senior Distinguished Engineer

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

[phone] New    Mobile: [phone]

[e-mail]<mailto:[e-mail]>

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