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

[Warren Kumari <[e-mail]>]

On Wed, Feb 2, 2022 at 1:32 PM <[e-mail]> 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:
>
>    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.
>
>

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