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

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

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

> > 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).
> >
> 
> I think you're implying something [subtle] here that I'm not following. If we
> can qualify this statement to the case that doesn't include the DSCP in
> flow identification.

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

> -----Original Message-----
> From: Lou Berger <[e-mail]>
> Sent: Wednesday, July 17, 2019 5:17 PM
> To: Black, David; [e-mail]
> Subject: Re: [Detnet] Diffserv concerns wrt: draft-ietf-detnet-ip-01.txt
> 
> 
> [EXTERNAL EMAIL]
> 
> Hi David,
> 
> Thank you for the comment see in line responses below.
> 
> 
> ----------
> On July 17, 2019 3:51:41 PM "Black, David" <[e-mail]> wrote:
> 
> > 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.
> >
> 
> 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.
> 
> > [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.
> >
> 
> 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.
> 
> 
> > [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).
> >
> 
> 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.
> .
> 
> > 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 think this is the qualification I was referring to above. If not, it
> would be helpful if you could clarify.
> 
> > 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.
> >
> 
> Agreed.
> 
> > 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!!").
> >
> 
> Agreed. Any specific text suggestions you have would be appreciated
> 
> Thanks again,
> Lou
> > Thanks, --David
> >
> >> -----Original Message-----
> >> From: detnet <[e-mail]> On Behalf Of internet-
> >> [e-mail]
> >> Sent: Monday, July 1, 2019 2:32 PM
> >> To: [e-mail]
> >> Cc: [e-mail]
> >> 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
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/detnet
> > _______________________________________________
> > detnet mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/detnet
>