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

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

Hi Toerless,

> IMHO both drafts describe the 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 ingress shaping,
> calculation of clock offsets (so developers of controllers will understand what they would
> need to do), and so on.

I would strongly encourage a single draft on the queueing/scheduling mechanism, separating out the encoding details (e.g., to separate sections in that single draft or to a separate draft or drafts).  Beyond that, specifying the details that implementers need to understand in order to produce interoperable implementations is always a good idea ;-).

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

While it certainly would have been convenient to have a small number of drafts that each cover both on-the-wire encoding of queuing/scheduling information and the queueing/scheduling mechanisms that make use of that information, that's (unfortunately) not the current situation.  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.

> 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

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.

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