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

[Balázs Varga A <[e-mail]>]

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

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