Re: [Detnet] DetNet working meetings on scaling/queueing

[Toerless Eckert <[e-mail]>]

On Mon, Apr 10, 2023 at 02:00:27PM +0000, Black, David wrote:
> In addition to these two drafts that propose different mechanisms to carry essentially the same cycle ID information for CQF, there are quite a few additional drafts (draft-<*>-detnet-<*>) that propose encoding mechanisms to carry queueing/scheduling information without specifying details on how that information is to be used by network nodes.

That sounds like incomplete specifications to me. But it could be the approach
of "we want some packet header providing us new type of code-points, but then we want
to configure proprietary and or elsewhere (not IETF) defined/standardized algorithms". 

> With the overall disclaimer that alternative proposals and discussion in the open working meetings are welcome and encouraged ...

> at the moment, I don't understand how to make progress on the plethora of on-the-wire information encoding proposals without a good understanding of what information needs to be encoded ... which in turn suggests focusing on the queueing/scheduling mechanisms to understand what information is needed (in the hope of only standardizing encoding mechanisms that carry information that will be used).  A simple example in this context is that transmission of cycle ID information only makes sense if we're going to standardize some extended form (or variant) of CQF that will use that cycle ID information.

Agreed. In draft-eckert-detnet-criteria-assessment, i have two critera classes:

4.10.2.  End-to-end packet header requirements
4.10.3.  Hop-by-hop packet header requirements

The end-to-end packet header requirements attempt to capture those parameters like a cycle identifier.

The hop-by-hop packet header reqquirements attempt to capture those parameters that would be
required on a hop-by-hop basis, aka: if there are 10 hops, they would need to be required 10 times.

First of all, we could try to capture these parameters on the wiki for the algorithms
when we review them in the meetings.

Secondly, we should try to understand where any new header work would need to go, to early
engage those WGs (if it is not DetNet), so that we proceed to work out the header details
in a way he respective WG wold agree.

The way i see it:
  - 6MAN for an IPv6 extension header - unless we could get an agreement with them that
    we (DetNet) can work on a particular subset ourselves (*)
  - MPLS or rather MPLS open design team (ODT) for MPLS
  - BIER for BIER header (where applicable)
  - "running around in circles" for IPv4 header (aka: once we've figured out 6MAN, MPLS, BIER),
    probably consulting with INTAREA and IOTOPS (as i am assuming that the IPv4 use case would
    be related to industrial networks that can not / want not use IPv6).

Other than that, i would be a fan of figuring out whether we could have a single "one-size-fits-all"
end-to-end header at least across all mechanisms we target to standardize (and even beyond),
by simply using the approach of DSCP: Aka: figure out how many new "code-point" type header
fields we need (and of which size), and then very much like DSCP instantiate a particular
algorithm through configuration of the semantic of the fields - in the same way as you
would configure e.g.: the (DiffServ) queue and drop/congestion parameters for each DSCP
value in todays DiffServ deployments.

And i would hope there is more to be learned from what DiffServ has done, that we hopefully
could reuse.

Cheers
    Toerless

> > (and i do mean this for all drafts on the table, not just our cyclic queuing ones).
> 
> I would agree.  It looks like I should put together some sort of tentative time budget agenda for the first open working meeting that includes time for this sort of discussion.  I'll try to get that out later today, and apologize for my day job preventing me from dealing with this upcoming meeting for most of last week ...

> Thanks, --David
> 
> -----Original Message-----
> From: Toerless Eckert <[e-mail]> 
> Sent: Sunday, April 9, 2023 11:51 PM
> To: Yizhou Li
> Cc: Black, David; [e-mail]
> Subject: Re: [Detnet] DetNet working meetings on scaling/queueing
> 
> 
> [EXTERNAL EMAIL] 
> 
> Thanks, Yizhou, agree.
> 
> David, *:
> 
> TO add from my side:
> 
> IMHO both drafts describe the same same underlying queuing mechanism. If there are discrepancies,
> then i think they would mostly be bugs/easily corrected. But the drafts differ in what type
> of details they include, each of us trying to include what we felt was necessary/important to
> capture - in my drafts case i was specifically trying to rely on pseudocode to describe the
> behavior and add systematic components based on WG feedback, such as minimal ingres shaping,
> calculation of clock offsets (so developers of controllers will understand what they would
> need to do), and so on.
> 
> I do also agree with Yizhou, that it would be good to understand what we would need to have in
> the standard track documents first, and then figure out what additional informational
> drafts would have to describe. From our first round of discussing this (back from the times
> of IETF Bangkok), i also had the impression that describing an actual on-the-wire encoding
> was the most easy way for the IETF to agree that a mechanism was describing something that
> requires standardization (on the wire interoperability).
> 
> I guess it would be useful to have in our upcoming regular meetings some discuss about
> what type of details proposals should include and how, and maybe how to break up or
> merge proposals so each draft is better in a shape of what ultimately a WG could adopt
> (and i do not mean this for all drafts on the table, not just our cyclic queuing ones).
> 
> Cheers
>     Toerless
> 
> 
> On Mon, Apr 10, 2023 at 02:32:25AM +0000, Yizhou Li wrote:
> > Hi David,
> > 
> > If we set aside MPLS label, DSCP, IP options, long/short fields etc, the scheduling mechanisms are quite similar.
> > 
> > >From the perspective of elaboration, there are some differences.
> > 
> > draft-yizhou-detnet-ipv6-options-for-cqf-variant explains more on what are the problems and which part of scheduling needs to be extended to adapt to large scale network and to migrate from fundamental 2-buffer or 3-buffer CQF.
> > 
> > It looks to me that IETF usually has no normative language to describe queueing or scheduling.
> > So if the group think it would be better to put scheduling as a standalone documents without touching how the info to be carried, I think it could be done by merging some text from both. Toerless and I started some conversations in IETF 116, maybe we can use some of the working session time to discuss this as well?
> > 
> > 
> > Thanks,
> > Yizhou
> > 
> > From: Black, David [mailto:[e-mail]]
> > Sent: Monday, April 10, 2023 9:50 AM
> > To: Yizhou Li <[e-mail]>; [e-mail]
> > Cc: Black, David <[e-mail]>
> > Subject: RE: DetNet working meetings on scaling/queueing
> > 
> > Hi Yizhou,
> > 
> > If we (temporarily) set aside where the cycle identification information is carried in each packet (that will need to be addressed, later), what are the differences between the scheduling mechanisms in  draft-yizhou-detnet-ipv6-options-for-cqf-variant and draft-eckert-detnet-tcqf ?
> > 
> > Thanks, --David
> > 
> > From: Yizhou Li <[e-mail]<mailto:[e-mail]>>
> > Sent: Sunday, April 9, 2023 8:52 PM
> > To: Black, David; [e-mail]<mailto:[e-mail]>
> > Cc: Black, David
> > Subject: RE: DetNet working meetings on scaling/queueing
> > 
> > 
> > [EXTERNAL EMAIL]
> > Hi David,
> > 
> > There is one more draft draft-yizhou-detnet-ipv6-options-for-cqf-variant-01 related to scheduling. Would you please add to the list?
> > 
> > I would like to  give a more detailed presentation if the time permits in one of the open working meetings.
> > 
> > Thanks,
> > Yizhou
> > 
> > 
> > From: detnet [mailto:[e-mail]] On Behalf Of Black, David
> > Sent: Saturday, April 8, 2023 5:13 AM
> > To: [e-mail]<mailto:[e-mail]>
> > Cc: Black, David <[e-mail]<mailto:[e-mail]>>
> > Subject: [Detnet] DetNet working meetings on scaling/queueing
> > 
> > With the first of these working meetings coming up next week (Tuesday evening or Wednesday morning depending on time zone - WebEx info here: https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/detnet/5Ckc25NPr3C-wsQ9Zv4RzsADM1I/__;!!LpKI!gizM0h3fVQri_CXVhbroAQZf_xfpXH3bB0Eb-5KA-XrRuJ98xkz-z2RHddbKJkpR5bbVEx-T9CaAvw$ [mailarchive[.]ietf[.]org] [mailarchive.ietf.org]<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/detnet/5Ckc25NPr3C-wsQ9Zv4RzsADM1I/__;!!LpKI!lBepWUdXMG3R80CH1JYnT2jDhXknUDZyZ_KtO0ByFw8eZOWuJLksyCBCFPxGHkzTPCwyDTD579RAm2oNvw$>), I thought I'd try to describe some expectations (and non-expectations).
> > 
> > These open working meetings will be less structured than DetNet meetings during IETF week or the interim meeting (no fixed time slots, discussion will not be entirely organized/oriented around slide decks).  The initial open working meeting focus will be queuing and packet scheduling within individual DetNet nodes, where we're aware of the following four drafts that propose node queuing or scheduling mechanisms:
> > 
> > draft-eckert-detnet-tcqf-02 Deterministic Networking (DetNet) Data Plane - Tagged Cyclic Queuing and Forwarding (TCQF)
> > 
> > draft-joung-detnet-asynch-detnet-framework-02 Asynchronous Deterministic Networking Framework for Large-Scale Networks
> > 
> > draft-peng-detnet-deadline-based-forwarding-05 Deadline Based Deterministic Forwarding
> > 
> > draft-peng-detnet-packet-timeslot-mechanism-01 Generic Packet Timeslot Scheduling Mechanism
> > 
> > If any drafts are missing from the above list (or any of the above drafts should be removed), please send a note to the list or directly to me with the WG chairs ([e-mail]<mailto:[e-mail]>) cc:'d.
> > 
> > The open working meetings will initially address three items:
> > 
> > 
> >   1.  Refining requirements: The scaling requirements draft (Requirements for Scaling Deterministic Networks) ought to be stable enough by the end of April that work invested in determining whether and to what extent the proposed mechanisms do/don't meet its requirements will not be wasted.
> > 
> > 
> > 
> >   1.  Longer presentations of the proposed mechanisms.  Each open working meeting ought to be able to accommodate one or two 40-45 minute slots for longer, more detailed presentations than have been possible during the limited time available in WG meetings - that would be 30-35 minutes of presentation, 10-15 minutes of questions.  With apologies for the short notice, authors of proposals who would like to do this at next week's meeting should please contact me and cc: the WG chairs.
> > 
> > 
> >   1.  Evaluation criteria.  It seems clear to me that we will need to look at evaluation criteria beyond the requirements draft - a process discussion of how to go about this in a reasonable and fair fashion seems appropriate (e.g., much as the effort that has gone into draft-eckert-detnet-criteria-assessment is worthy, the author has been open and honest about being a proponent of one of the solutions - I don't like the optics of the group for one of the proposal drafts being in charge of writing the evaluation criteria for all of the proposals).
> > 
> > Please keep in mind that these open working meetings cannot make decisions for the WG - any suggestions/recommendations that emerge will have to be taken to this mailing list for further discussion.
> > 
> > Comments, questions and alternate suggestions are welcome.
> > 
> > Thanks, --David
> > 
> > David L. Black, Sr. Distinguished Engineer, Technology & Standards
> > Infrastructure Solutions Group, Dell Technologies
> > mobile [phone] [e-mail]<mailto:[e-mail]>
> > 
> 
> -- 
> ---
> [e-mail]
> 

-- 
---
[e-mail]