Subject: [Detnet] Diffserv concerns wrt: draft-ietf-detnet-ip-01.txt

From: "Black, David" <[email-masked]>
Date: Wed, 17 Jul 2019 19:50:01 +0000

Found a few things that need attention in this draft.

[1] First, a "MUST fix" in Section 5.1.1.4:

5.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 bitmask based matching, where bits set to one (1) in the
   bitmask indicate which subset of the bits in the field are to be used
   in determining a match.  Note that all bits set to zero (0) value as
   a bitmask effectively means that these fields are ignored.

That won't fly, as using a DSCP bitmask conflicts with this paragraph in
Section 3 of RFC 2474 (https://tools.ietf.org/html/rfc2474#section-3):

   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 draft's text starting from "Implementations MUST" through the
end of that paragraph needs to be rewritten to align with RFC 2474.

[2] Second, a smaller "MUST fix" in Section 6, where this:

   o  IPv4 Type of Service and IPv6 Traffic Class Fields.

is listed as part of the Management and Control information.  That
item needs to be changed to specify only the 6-bit DSCP portions of
those fields (see RFC 2474), otherwise the DetNet Management and
Control functionality may get confused by the ECN info that is in the
other two bits of those IP header fields.  The ECN info should be
masked off and not visible to DetNet management and control. 

[3] Finally, some clarification on 6-tuple is in order, starting from
this text in Section 3 (DetNet IP Data Plane Overview):

   The DetNet IP data plane uses "6-tuple" based flow identification,
   where 6-tuple refers to information carried in IP and higher layer
   protocol headers.  The 6-tuple referred to in this document is the
   same as that defined in [RFC3290].

That text is fine as far as it goes, but I see a couple of additional
considerations:

a) Each 5-tuple (i.e., 6-tuple without DSCP) can be used for at most one
    DetNet flow, i.e., the flow identifications of any two separate DetNet
    flows MUST differ in at least one component of the 5-tuple (or MUST
    NOT differ only in the DSCP).

b) There are Diffserv situations in which a single flow can use multiple
    6-tuples that differ only in DSCP.  Diffserv AF (Assured Forwarding) is
    the important example, see RFC 2597.

I believe that text needs to be added to make a) clear.  Section 4.3.2
(Quality of Service) to avoid cluttering up the overview in section 3.

The situation in b) is different, and I think b) can be characterized as
inapplicable to DetNet, as the only important Diffserv example is
multiple AF drop precedences - multiple drop precedences make no
sense in a DetNet flow that never experiences drops if the network is
functioning correctly.   It would help to add a sentence somewhere to
state this and that use of  multiple AF drop precedences in a single
DetNet flow is prohibited.  Again, Section 4.3.2 looks like a good place
to do that.

The possible use of multiple drop precedences gets more "interesting"
if multiple drop precedences need to be supported end-to-end in
order to affect drop treatment of a flow in the non-DetNet portion of
the flow's network path, but I would hope that this idea is simply out
of scope for DetNet as a "Doctor, it hurts when I do this" topic (i.e.,
the response is "Don't do that!!").
		
Thanks, --David

> -----Original Message-----
> From: detnet <[email-masked]> On Behalf Of internet-
> [email-masked]
> Sent: Monday, July 1, 2019 2:32 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Detnet] I-D Action: draft-ietf-detnet-ip-01.txt
> 
> 
> [EXTERNAL EMAIL]
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Deterministic Networking WG of the IETF.
> 
>         Title           : DetNet Data Plane: IP
>         Authors         : Balázs Varga
>                           János Farkas
>                           Lou Berger
>                           Don Fedyk
>                           Andrew G. Malis
>                           Stewart Bryant
>                           Jouni Korhonen
> 	Filename        : draft-ietf-detnet-ip-01.txt
> 	Pages           : 22
> 	Date            : 2019-07-01
> 
> Abstract:
>    This document specifies the Deterministic Networking data plane when
>    operating in an IP packet switched network.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-detnet-ip/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-detnet-ip-01
> https://datatracker.ietf.org/doc/html/draft-ietf-detnet-ip-01
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-detnet-ip-01
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> detnet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/detnet

---

From: Lou Berger <[email-masked]>
Date: Wed, 17 Jul 2019 17:16:37 -0400

Hi David,

Thank you for the comment see in line responses below.

----------

> end of that paragraph needs to be rewritten to align with RFC 2474.

I think you had mentioned this before. I'm sorry I didn't catch that it 
hadn't been fixed. believe we also discussed that this is a pretty 
straightforward fix and it just needs to be changed to a list of values.

> masked off and not visible to DetNet management and control.

I'm not sure I follow this. My understanding was that the use of ecn should 
be controllable by the detnet controller plane.  I'm sure we can work out 
some language that makes it clear that we have two subfields here to be 
dealt with. perhaps this is a good conversation for our face-to-face 
meeting next week.

>     NOT differ only in the DSCP).

I think you're implying something settle here that I'm not following. If we 
can qualify this statement to the case that doesn't include the DSCP in 
flow identification.
.

>     the important example, see RFC 2597.
I think this is the qualification I was referring to above. If not, it 
would be helpful if you could clarify.

> (Quality of Service) to avoid cluttering up the overview in section 3.

Agreed.

> the response is "Don't do that!!").

Agreed. Any specific text suggestions you have would be appreciated

Thanks again,
Lou

---

From: "Black, David" <[email-masked]>
Date: Wed, 17 Jul 2019 22:17:11 +0000

Hi Lou,

Thanks for the quick response.

On [1], it looks like there's an understanding of what needs to be done.

On [2], I concur with the suggestion to talk further in Montreal, as I'm not completely clear on the intended purpose/use of the list of control and management items in Section 6, which will affect what ought to be said about the ECN subfield

On [3]b) , we agree on the "Don't Do That!!" approach to multiple DSCPs in a single DetNet flow - I'll try to draft some text to express that in my "copious spare time."

That leaves [3]a) - here's an attempt at further explanation ...

> I think you're implying something [subtle] here that I'm not following. If we

Sure ... DetNet uses 6-tuples (2 IP addresses, transport protocol, 2 ports, DSCP) for flow identification.   The first 5 components of a 6-tuple (2 IP addresses, transport, 2 ports) constitute a 5-tuple, which has to suffice for flow identification, even if DetNet implementations actually use 6-tuples for that purpose.   Here are a couple of attempts to further explain from different aspects:

i) It's ok for an network node to use 6-tuples (with DSCP) for flow identification long as 5-tuples would have sufficed if they had been used.  Attempting a more concrete example, if the zero (best effort) DSCP is never used for DetNet traffic, there may be network node implementation benefits to quickly kicking best effort traffic into the non-DetNet forwarding plane based on DSCP alone.   An implementation might realize this by initially run all traffic through a filter that uses a few DSCPs (e.g., the default DSCPs for EF and AF41) to separate out a small "might be DetNet" traffic fraction from a much larger "is definitely not DetNet" traffic fraction, and then send all "might be DetNet" traffic through full 5-tuple (or 6-tuple) match to determine which traffic is actually DetNet, passing traffic that is not DetNet to the non-DetNet forwarding plane.

ii) If one starts with a DetNet flow identified by a 6-tuple and changes any of the first 5 components of the tuple, the resulting 6-tuple MAY identify another DetNet flow ... or may not identify anything useful.  In contrast, if one takes a DetNet flow identified by a 6-tuple and changes only the DSCP, the resulting 6-tuple MUST NOT identify another DetNet flow - if it identifies any traffic, that's likely to be an indication that something's wrong.

I hope that helps.

Thanks, --David

> From: Lou Berger <[email-masked]>
> Sent: Wednesday, July 17, 2019 5:17 PM
> To: Black, David; [email-masked]
> Subject: Re: [Detnet] Diffserv concerns wrt: draft-ietf-detnet-ip-01.txt
> 
> 
> [EXTERNAL EMAIL]
> 
> Hi David,
>