Subject: [Dots] /tm-setup RE: New Version Notification for draft-ietf-dots-telemetry-05.txt

From: <[email-masked]>
Date: Fri, 3 Apr 2020 13:48:49 +0000

Re-,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Jon Shallow [mailto:[email-masked]]
> Envoyé : vendredi 3 avril 2020 13:51
> À : BOUCADAIR Mohamed TGI/OLN; Konda, Tirumaleswar Reddy; kaname
> nishizuka; [email-masked]
> Objet : RE: [Dots] New Version Notification for draft-ietf-dots-
> telemetry-05.txt
> 
> Hi Med,
> 
> Thanks for this.  It looks as if it might be going in the right
> direction - I need to check if it can be sensibly coded up.
> 
> Hi all,
> 
> Some further thoughts.
> 
> 
> /tm-setup
> ========
> 
> When doing a GET with cuid=, but not tsid= (to get the max/min etc.
> configuration information) what should be returned in the tsid field
> in the response given that it is a key?

[Med] Good catch. This one has to be fixed. 

> 
> While the baseline information is certainly worthwhile, things can
> wildly fluctuate during, say, Black Friday sales, or sales for some
> major festival.  The baseline then really needs to be updated for when
> these flash crowds take place to prevent unnecessary mitigation.  The
> text should be updated to reflect that there may be changing
> baselines. - e.g. extra servers spun up to handle the additional
> expected loads.

[Med] Good point. 

> 
> Peak Embryonic connection counts are a function of the listen queue
> (backlog) sizes on the target server and are likely to be different
> per port.  I am not sure that over my time in the last 2 decades
> working with DDoS that I have come across that many people who are
> able to sensibly answer the embryonic max question - especially when
> SYN Cookies and other techniques can muddy the water.  There is
> benefit in reporting it (e.g. SYN flooding attack) but I think it is
> difficult to baseline.  Thoughts?
> 

[Med] This is a fair observation. We wanted to share any information that might be available to help detect abnormal patterns. This does not mean that all these items need to be present. I'd like to hear more from the group.

---

From: <[email-masked]>
Date: Fri, 3 Apr 2020 18:59:26 +0000

Jon, 

> [Med] Good catch. This one has to be fixed.

[Med] This is the new tree structure for telemetry. If no tsid is present, only "ro" items will be returned.

    +--:(telemetry-setup) {dots-telemetry}?
    |  +--ro max-config-values
    |  |  +--ro measurement-interval?          interval
    |  |  +--ro measurement-sample?            sample
    |  |  +--ro low-percentile?                percentile
    |  |  +--ro mid-percentile?                percentile
    |  |  +--ro high-percentile?               percentile
    |  |  +--ro server-originated-telemetry?   boolean
    |  |  +--ro telemetry-notify-interval?     uint32
    |  +--ro min-config-values
    |  |  +--ro measurement-interval?        interval
    |  |  +--ro measurement-sample?          sample
    |  |  +--ro low-percentile?              percentile
    |  |  +--ro mid-percentile?              percentile
    |  |  +--ro high-percentile?             percentile
    |  |  +--ro telemetry-notify-interval?   uint32
    |  +--ro supported-units
    |  |  +--ro unit-config* [unit]
    |  |     +--ro unit           unit-type
    |  |     +--ro unit-status?   boolean
    |  +--rw telemetry* [cuid tsid]
    |     +--rw cuid                         string
    |     +--rw cdid?                        string
    |     +--rw tsid                         uint32
    |     +--rw (setup-type)?
    |        +--:(telemetry-config)
    |        |  +--rw current-config
    |        |     +--rw measurement-interval?          interval
    |        |     +--rw measurement-sample?            sample
    |        |     +--rw low-percentile?                percentile
    |        |     +--rw mid-percentile?                percentile
    |        |     +--rw high-percentile?               percentile
    |        |     +--rw unit-config* [unit]
    |        |     |  +--rw unit           unit-type
    |        |     |  +--rw unit-status?   boolean
    |        |     +--rw server-originated-telemetry?   boolean
    |        |     +--rw telemetry-notify-interval?     uint32
    |        +--:(pipe)
    |        |  +--rw total-pipe-capacity* [link-id unit]
    |        |     +--rw link-id     nt:link-id
    |        |     +--rw capacity    uint64
    |        |     +--rw unit        unit
    |        +--:(baseline)

---

From: "Jon Shallow" <[email-masked]>
Date: Fri, 3 Apr 2020 20:54:15 +0100

Hi Med,

This looks good - I will give it a go to check nothing else creeps out of
the woodwork!

Thanks for all your help here and clear thinking.

Regards

Jon

> -----Original Message-----
> From: Dots [mailto: [email-masked]] On Behalf Of
[email-masked]
> Sent: 03 April 2020 19:59
> To: Jon Shallow; Konda, Tirumaleswar Reddy; kaname nishizuka;
[email-masked]
> Subject: Re: [Dots] /tm-setup RE: New Version Notification for
draft-ietf-dots-
> [Med] This is the new tree structure for telemetry. If no tsid is present,
only "ro"
> items will be returned.
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: <[email-masked]>
Date: Sat, 4 Apr 2020 09:42:05 +0000

Hi Jon,

Great. The full updated tree structure can be found at:

https://github.com/boucadair/draft-dots-telemetry/blob/master/tree-04.txt 

Cheers,
Med

> Envoyé : vendredi 3 avril 2020 21:54
> À : BOUCADAIR Mohamed TGI/OLN; [email-masked]
> Objet : RE: [Dots] /tm-setup RE: New Version Notification for draft-
> ietf-dots-telemetry-05.txt
> 
> Hi Med,
>

---

From: "Jon Shallow" <[email-masked]>
Date: Sat, 4 Apr 2020 16:21:48 +0100

Hi All,

A suggested change to reduce the information sent back when asking for all
the tmids and tsids as the requesting client will have the same cuid and I
think the same cdid.
[Saves 22 bytes + CBOR overhead and same for cdid each time]

OLD:
    +--:(telemetry) {dots-telemetry}?
       +--rw pre-or-ongoing-mitigation* [cuid tmid]
          +--rw cuid                             string
          +--rw cdid?                            string
          +--rw tmid                             uint32
NEW:
    +--:(telemetry) {dots-telemetry}?
       +--rw cuid                             string
       +--rw cdid?                            String
       +--rw pre-or-ongoing-mitigation* [tmid]
          +--rw tmid                             uint32

OLD:
..

NEW:
    +--:(telemetry-setup) {dots-telemetry}?
    |  +--ro max-config-values
..
    |  +--rw cuid                         string
    |  +--rw cdid?                        string
    |  +--rw telemetry* [tsid]
    |     +--rw tsid                         uint32

The same is true for signal mids, but I guess that is too late now.  Sigh.

           +--:(mitigation-scope)
           |  +--rw scope* [cuid mid]
           |     +--rw cdid?                   string
           |     +--rw cuid                    string
           |     +--rw mid

Regards

Jon
> Sent: 04 April 2020 10:42
> To: Jon Shallow; [email-masked]
draft-ietf-dots-

---

From: <[email-masked]>
Date: Sat, 4 Apr 2020 15:50:07 +0000

Hi Jon,

cuid and cdid MUST NOT be returned in the message body.

That's said, I'm OK with the proposes change. 

Cheers,
Med

> Envoyé : samedi 4 avril 2020 17:22
> > > This looks good - I will give it a go to check nothing else creeps
> out
> > > of
> > > the woodwork!
> > >
> > > > > > When doing a GET with cuid=, but not tsid= (to get the
> max/min
> > > etc.
> > > > > > configuration information) what should be returned in the
> tsid
> > > field
> > > > [Med] This is the new tree structure for telemetry. If no tsid
> is
> > > present,
> > > only "ro"
> > > > items will be returned.
> > > >
> > > >

---

From: "Jon Shallow" <[email-masked]>
Date: Sat, 4 Apr 2020 17:01:35 +0100

Hi Med,

Yes, you are right - I had fallen into the trap of making sure that what was
in the tree that was non optional was returned - and had forgotten the
statement that was in the signal draft.

So, the change then becomes a cosmetic one.

Regards

Jon

> Sent: 04 April 2020 16:50
draft-ietf-dots-

---

From: <[email-masked]>
Date: Sat, 4 Apr 2020 16:06:25 +0000

Re-, 

I will add a note to the document. 

FYI, the tree is updated on the github. 

Thank you. 

Cheers,
Med

> Envoyé : samedi 4 avril 2020 18:02
> > > A suggested change to reduce the information sent back when asking
> for
> > > all
> > > the tmids and tsids as the requesting client will have the same
> cuid
> > > and I
> > > think the same cdid.
> > > The same is true for signal mids, but I guess that is too late
> now.
> > > Sigh.
> > >
> > >            +--:(mitigation-scope)
> > > > https://github.com/boucadair/draft-dots-
> telemetry/blob/master/tree-
> > > 04.txt
> > > >
> > > > Cheers,
> > > > Med
> > > >
> > > >

---

From: "Jon Shallow" <[email-masked]>
Date: Mon, 6 Apr 2020 11:01:53 +0100

Hi Med,

Thanks for posting the new tree.

I have gone back to trying to implement it and realise it needs to be
thought through further.

My suggestion of moving cuid and cdid up a level looks to be incorrect.  The
top level should be an array, of which cuid is a key as that is a
representation of the database behind all this that holds all the
information under the /tm-setup resource (same is true for /tm resource).

The second issue is that current-configuration, pipe and baseline are not
allowed to be specified at the same time (as I understand it to be able to
easily handle conflicts etc.).  They all have tsid as a key, but the tsid
across all 3 components may not be the same and updating 1 component with a
new tsid does not invalidate either of the other 2 components - only the
updated component is deleted and a new one created.  

A way forward could be to no longer make telemetry an array, but make each
of the 3 components an array indexed by tsid.  Then it is a lot easier
programmatically to handle individual components being updated.  Otherwise I
am finding that I am having to give each component their own telemetry array
element and then merging / demerging things as things get updated.

However, it is not immediately obvious how best to make each of the 3
components an array indexed by tsid if this is a better way to go forward.

The response to a GET for a tsid returns any of the 3 components that match
the tsid - as before, so no different here other than they are not returned
under a single telemetry array entry.

There is some ambiguity in the PUT /tm-setup - we have

   tsid:  Telemetry Setup Identifier is an identifier for the DOTS
        telemetry setup configuration data represented as an integer.
        This identifier MUST be generated by DOTS clients.  'tsid'
        values MUST increase monotonically (when a new PUT is generated
        by a DOTS client to convey new configuration parameters for the
        telemetry).

And

   o  If the DOTS server finds the 'tsid' parameter value conveyed in
      the PUT request in its configuration data and if the DOTS server
      has accepted the updated configuration parameters, 2.04 (Changed)
      MUST be returned in the response.

Where the latter assumes we can use the same tsid.  Are we allowed to use
the same tsid to update a configuration component or MUST we use a new tsid?

Regards

Jon

> Sent: 04 April 2020 17:06
draft-ietf-dots-

---

From: <[email-masked]>
Date: Mon, 6 Apr 2020 10:37:49 +0000

Re-,

Please see inline. 

Cheers,
Med

> Envoyé : lundi 6 avril 2020 12:02
> representation of the database

[Med] Hmm. I would agree with you if we are using YANG to model what happened at the server side to manage its state, but we are not using YANG for that. We are using YANG to model requests. As such, your modification is correct as a request includes one and only one cuid. I will add a note to the draft to remind this. 

 behind all this that holds all the
> information under the /tm-setup resource (same is true for /tm

[Med] Idem as above

> easily handle conflicts etc.). 

[Med] I confirm. 

 They all have tsid as a key, but the
> tsid
> across all 3 components may not be the same

[Med] It is not the same.

 and updating 1 component
> with a

[Med] I confirm. 

> of the 3 components an array indexed by tsid.

[Med] That's would work for pipe and baseline, but not for the telemetry-config. Telemetry-config is not an array on its own. 

  Then it is a lot easier
> components an array indexed by tsid if this is a better way to go

[Med] For this to work, I'm afraid that these have to be indexed using distinct keys. 

> the same tsid to update a configuration component or MUST we use a new

[Med] This is to cover retransmitted requests.

> > > Yes, you are right - I had fallen into the trap of making sure
> that
> > > what was
> > > > > > > Objet : RE: [Dots] /tm-setup RE: New Version Notification
> for
> > > > > draft-
> > > > > > > This looks good - I will give it a go to check nothing
> else
> > > creeps
> > > > > out
> > > > > > > of
> > > > > > > the woodwork!
> > > > > > >
> > > > > > > > Subject: Re: [Dots] /tm-setup RE: New Version
> Notification
> > > for
> > > > > > > draft-ietf-dots-
> > > > > > > > telemetry-05.txt
> > > > > > > >
> > > > > > > > Jon,
> > > > > > > >
> > > > > > > >
> > > > > > > > > >
> > > > > > > > > > /tm-setup
> > > > > > > > > > ========
> > > > > > > > > >
> > > > > > > > > > configuration information) what should be returned
> in
> > > the
> > > > > tsid
> > > > > > > field
> > > > > > > > [Med] This is the new tree structure for telemetry. If
> no
> > > tsid
> > > > > is
> > > > > > > present,
> > > > > > > only "ro"
> > > > > > > > items will be returned.
> > > > > > > >
> > > > > > > >