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

From: Warren Kumari via Datatracker <[email-masked]>
Date: Wed, 02 Feb 2022 09:00:13 -0800

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.

---

From: <[email-masked]>
Date: Wed, 2 Feb 2022 18:32:01 +0000

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 <[email-masked]>
> Envoyé : mercredi 2 février 2022 18:00
> À : The IESG <[email-masked]>
> Cc : [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Objet : Warren Kumari's Discuss on draft-ietf-dots-telemetry-20: (with
> 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:
> 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.

---

From: Warren Kumari <[email-masked]>
Date: Wed, 2 Feb 2022 14:09:26 -0500

On Wed, Feb 2, 2022 at 1:32 PM <[email-masked]> wrote:

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

Harumph... grumble... I still think that this is icky, but I'll clear my
discuss.

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

Yah. If you are going to have mega[bits|bytes], you might as well also
include T, P, Z, etc. Hopefully we'll have solved the DoS problems before
we need to use zetta, but I suspect not :-)

I'll go clear, thanks for responding,

W

>
>
> 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:
>
> 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,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;

-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra