Re: [Dots] Warren Kumari's Discuss on draft-ietf-dots-telemetry-20: (with DISCUSS)

[[e-mail]]

Hi Warren, 

We need to keep in mind that the data that will be shared by a DOTS agent may not be computed/measured locally, but be provided by another (external) entity. Having the support for the tree unit classes eases the injection of such external data into the telemetry machinery without any need for adjustment/conversion between unit classes. 

Because we need to ensure for compact encoding, unit auto-scaling is recommended and as such many units for each unit-class should be supported. 

We could stop at tera-* or peta-* as largest unit given that nowadays DDoS attacks are already exceeding TBps. However, and given that we are using enumerations, it will be difficult to define new values in the future if needed. This is why we included support for exa-* and zetta-* as a provision. 

Note that units can be easily augmented if we used identities rather than enumerations, but we went for enumerations for reasons recorded in the document:  

   The DOTS telemetry module (Section 11.1) uses "enumerations" rather
   than "identities" to define units, samples, and intervals because
   otherwise the namespace identifier "ietf-dots-telemetry" must be
   included when a telemetry attribute is included (e.g., in a
   mitigation efficacy update).  The use of "identities" is thus
   suboptimal from a message compactness standpoint; one of the key
   requirements for DOTS Signal Channel messages.

Cheers,
Med

> -----Message d'origine-----
> De : Warren Kumari via Datatracker <[e-mail]>
> Envoyé : mercredi 2 février 2022 18:00
> À : The IESG <[e-mail]>
> Cc : [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Objet : Warren Kumari's Discuss on draft-ietf-dots-telemetry-20: (with
> DISCUSS)
> 
> Warren Kumari has entered the following ballot position for
> draft-ietf-dots-telemetry-20: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/blog/handling-iesg-ballot-
> positions/
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dots-telemetry/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Please note: This really is just a DISCUSSion - I'm happy to be educated
> / wrong, but I do think that it is important enough that it gets
> addressed.
> 
> The 'unit-class' and 'unit' enumerations seems like they add a large
> amount of complexity for (AFAICT) very little gain. Do you really need:
>              "Packets per second (pps).";
>              "Bits per Second (bps).";
>              "Bytes per second (Bps).";
>              "Kilo packets per second (kpps).";
>              "Kilobits per second (kbps).";
>              "Kilobytes per second (kBps).";
>              "Mega packets per second (Mpps).";
>              "Megabytes per second (MBps).";
>              "Giga packets per second (Gpps).";
>              "Gigabits per second (Gbps).";
>              "Gigabytes per second (GBps).";
>              "Tera packets per second (Tpps).";
>              "Terabits per second (Tbps).";
>              "Terabytes per second (TBps).";
>              "Peta packets per second (Ppps).";
>              "Petabits per second (Pbps).";
>              "Petabytes per second (PBps).";
>              "Exa packets per second (Epps).";
>              "Exabits per second (Ebps).";
>              "Exabytes per second (EBps).";
>              "Zetta packets per second (Zpps).";
>              "Zettabits per second (Zbps).";
>              "Zettabytes per second (ZBps)."
> when just Packets Per Second and Bits Per Second would work? Yes, you
> might have to have a really large number in BPS, but that seems much
> much less likely to lead to errors than having parsers have to deal with
> this. When a user enters a number their glass would presumably allow
> them to use a more convenient unit, but having it encoded and decoded
> into this seems needlessly complex.
> 
> I did look through the document and list to try and find discussions on
> this point - I'm happy to be pointed at a place where it was discussed
> and agreed.
> 
> 
> 
> 


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.