Re: [Detnet] PREOF signaling

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Toerless

Many thanks for this!

Please see below:

> -----Original Message-----
> From: Toerless Eckert <[e-mail]>
> Sent: mercredi 16 février 2022 18:36
> To: Pascal Thubert (pthubert) <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [Detnet] PREOF signaling
> 
> Pascal, *:
> 
> Thanks a lot for the HbH header work!
> 
> (Q: Remind me, which one is the UDP encap ?)
> 

That's draft-varga-detnet-ip-preof



> The HbH header document has a lot of interesting, but quite novel ideas
> that should further be discussed. In general i think we should separate
> the data model we want for DetNet services from the encapsulation, aka:
> create one document where we define the desired data model (in an
> extensible fashion), and then one or more encapsulations reusing the same
> data model.
> 

Works for me


> Ideally the encapsulation documents would not need to be updated when we
> add more data model items, e.g.: by use of appropriate registry
> definition. Aka:
> the encoding rules should come from the registry or be pre-defined for all
> supportable data-model extensions.

To be balanced with the need for a simple / hard coded format for hardware consumption


> 
> Wrt to the data items proposed:
> 
> - In MPLS we have other than just 32/8 bit sequence number counters, so i
> think
>   we should have a data model which is a superset of what we have in MPLS
> to
>   ease migration.
> 

OK


> - The text is a bit euphemistic on the use of timestamps instead of
> sequence
>   numbers (great marketing ;-). I think for fairness it should mention
> also key downsides:
> 
>   - It does not permit to detect loss

Agreed

> 
>   - The elimination function becomes much harder to implement at high
> speeds,
>     because efficient methods of matching duplicates (bitmasks for
> sequence
>     number spaces) cannot be used.

Maybe so. Again I have hardware in mind and we're looking at a plain bitwise compare.


> 
> Overall, i think that timestamps for PREOF would be even more of a new
> DetNet QoS feature as T-CQF is for bounded latency (draft-eckert-detnet-
> mpls-tc-tcqf), which does not even introduce new packet headers, but just
> new algorithms inside the hops.

Time stamp is probably very hard to realize with current hardware. So I see that piece of the draft as a placeholder for a discussion. Should we propose it now so the hardware evolves sometime? Or drop it knowingly? Note that the time stamp would also sell as a way to detect whether a packet is "late" in which case it can be "accelerated" as a more intelligent "aging".

> 
> Aka: I am all for being more innovative in DetNet, but our really very
> conservative and very well vetted T-CQF mechanism has not been making
> progress in DetNet for about 4 years now, so i would really appreciate if
> we would also consider that such long waiting work would be taken care of
> in the WG. Especially (and this is another linkage to your draft) when we
> would start introducing new data-models and not taking the data items
> required for example for T-CQF also into account).

Good discussion, that would really be another EH that could be added to this draft as a suboption to the path information.

I guess the point you make on the data model applies there to.
At the moment both drafts appear as proposals to do some work. Whether it is published with the data model or the data model comes separate, before or after, depends on whether we agree to do the work in the first place.

Keep safe;

Pascal



> 
> Cheers
>     Toerless
> 
> On Sun, Feb 13, 2022 at 08:22:00AM +0000, Pascal Thubert (pthubert) wrote:
> > Dear WG
> >
> > The HbH draft is soon to expire, and I do not see that we had a deep
> discussion and a consensus on which kind of signaling will work best for
> DetNet IPv6.
> >
> > We have a proposal to encapsulate over UDP, which appears ready for
> adoption, and one to use IPv6 extension headers, which is ready to expire;
> arguments on the table include:
> >
> > Size of the encapsulation
> > Complexity of silicon implementation
> > Reuse of MPLS design
> > IP version independence
> > DetNet and SRv6
> > Flow vs path (the pipe and the water)
> >
> > I believe that each of those topics deserves a solid discussion before
> the group jumps on the UDP solution. The wrong decision now could mean a
> lot of wasted effort in the future.
> >
> > Regards,
> >
> > Pascal
> >
> > Début du message transféré :
> >
> > De: IETF Secretariat <[e-mail]>
> > Date: 13 février 2022 à 09:04:11 UTC+1
> > À: [e-mail]
> > Objet: Expiration impending: <draft-pthubert-detnet-ipv6-hbh-06.txt>
> >
> > The following draft will expire soon:
> >
> > Name:     draft-pthubert-detnet-ipv6-hbh
> > Title:    IPv6 Options for DetNet
> > State:    I-D Exists
> > Expires:  2022-02-25 (in 1 week, 4 days)
> >
> >
> 
> > _______________________________________________
> > detnet mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/detnet
> 
> 
> --
> ---
> [e-mail]