Subject: Re: [ippm] AD Evaluation of draft-ietf-ippm-twamp-yang-06

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 5 Apr 2018 15:34:50 -0700

Spencer,

Here is the response I got from one of the co-authors, Ruth, on the question below.

> On Mar 29, 2018, at 9:45 PM, Mahesh Jethanandani <[email-masked]> wrote:
> 
>> I'm not questioning this text,
>> 
>>   If the user has no network access to the Control-Client device, then
>>    the only option is to retrieve all test-session instances from the
>>    Session-Reflector device.  This could be problematic if a large
>>    number of test sessions are currently active on that device.
>> 
>> but I am trying to understand what type of problems you're thinking of (delays in starting testing from the Control-Client device, because the Session-Reflector is heavily loaded? Interference with current test sessions? Or something else), and find myself guessing.

Well it only makes sense in the context of the previous paragraphs – The whole text is given below:

Instances of twampSessionReflector:twampReflectorTestSession are indexed by a session identifier (SID). This is a value that is auto-allocated by the Server as test session requests are received, and communicated back to the client in the SID field of the Accept-Session field.
When attempting to retrieve operational data for active test sessions from a Session-Reflector device, the user will not know what sessions are currently active on that device, or what SIDs have been auto-allocated for these test sessions. If the user has network access to the Control-Client device, then it is possible to read the data for this session under twampClient:twampCtrlSession:twampSessionRequest and obtain the SID.The user may then use this SID value as an index to retrieve an individual twampSessionReflector:twampReflectorTestSession instance on the Session-Reflector device.
…. (and then the final paragraph.)
  If the user has no network access to the Control-Client device, then
   the only option is to retrieve all test-session instances from the
   Session-Reflector device.  This could be problematic if a large
   number of test sessions are currently active on that device.

So what the description as a WHOLE (including the previous paragraphs) is saying, is that if you want to read operational data for a SINGLE specific test session that is in progress on the server, you have a problem.  Test sessions as configured on the client have a NAME to identify them, but an instance of this test session in execution has a dynamically allocated test Session ID – and this is the ID you use for retrieving the OPERATIONAL status data for that test session on the Server while it is running.  You can’t use the test session name to retrieve operational data for this test session on the server – the test session name is not part of any TWAMP message exchange, it’s something we use on the client to give a key for a particular test session configuration (on the client) – so the server has no knowledge of the name.   The only thing the server does know (and this is what it indexes its operational data for test sessions in progress by) is the session ID that was dynamically allocated (by the server itself as it accepted this incoming test session  (and which IS communicated back to the client in a TWAMP message exchange).
So, what does the user do if he wants to retrieve operational data for a single specific test session from the SERVER while that test session is running?  He doesn’t know what SID the server dynamically allocated to his particular test session.
There are 2 options.  The FIRST 2 paragraphs describe how you can go to the CLIENT, retrieve operational data for the test session on the CLIENT using the test session NAME – and part of that operational data will be the dynamically allocated SID for that session (which the server communicated back to the client during the message exchange).  You can then go to the server and use that SID as a key to retrieve the individual  record for that test session’s operational data on the server.
OR  (And this is what the individual paragraph you were quoting was) 
IF you have no access to the client, then you’re screwed, because you don’t know the dynamically allocated SID for your session’s name, and you can’t go to the client and get it. So all you can do is effectively do a get/get next of ALL the operational data records for all test sessions currently  in progress on the server, and then try to locate the session you actually wanted to look at, based on other information (e.g. IP addresses, UDP ports, etc) to identify it.  And this may be problematic if a large number of test sessions are currently active on that (server) device.  Because you might have 3000 active sessions on that server device and now you’re going to have to sift through all 3000 returned records looking for the one you were actually interested in.
 
Hope this makes sense!

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 5 Apr 2018 19:30:54 -0500

Hi, Manesh,

On Thu, Apr 5, 2018 at 5:34 PM, Mahesh Jethanandani <[email-masked]
> wrote:

> but I am trying to understand what type of problems you're thinking of
> (delays in starting testing from the Control-Client device, because the
> Session-Reflector is heavily loaded? Interference with current test
> sessions? Or something else), and find myself guessing.
>
>
>
> Instances of twampSessionReflector:twampReflectorTestSession are indexed
> by a session identifier (SID). This is a value that is auto-allocated by
> the Server as test session requests are received, and communicated back to
> the client in the SID field of the Accept-Session field.
> When attempting to retrieve operational data for active test sessions from
> a Session-Reflector device, the user will not know what sessions are
> currently active on that device, or what SIDs have been auto-allocated for
> these test sessions. If the user has network access to the Control-Client
> device, then it is possible to read the data for this session under
> twampClient:twampCtrlSession:twampSessionRequest and obtain the SID.The
> user may then use this SID value as an index to retrieve an individual
> twampSessionReflector:twampReflectorTestSession instance on the
> Session-Reflector device.
> *  If the user has no network access to the Control-Client device, then*
> *   the only option is to retrieve all test-session instances from the*
> *   Session-Reflector device.  This could be problematic if a large*
> *   number of test sessions are currently active on that device.*
>
>
> So what the description as a WHOLE (including the previous paragraphs) is
> saying, is that if you want to read operational data for a SINGLE specific
> test session that is in progress on the server, you have a problem.  Test
> sessions as configured on the client have a NAME to identify them, but an
> instance of this test session in execution has a dynamically allocated test
> Session ID – and this is the ID you use for retrieving the OPERATIONAL
> status data for that test session on the Server while it is running.  You
> can’t use the test session name to retrieve operational data for this test
> session on the server – the test session name is not part of any TWAMP
> message exchange, it’s something we use on the client to give a key for a
> particular test session configuration (on the client) – so the server has
> no knowledge of the name.   The only thing the server does know (and this
> is what it indexes its operational data for test sessions in progress by)
> is the session ID that was dynamically allocated (by the server itself as
> it accepted this incoming test session  (and which IS communicated back to
> the client in a TWAMP message exchange).
> So, what does the user do if he wants to retrieve operational data for a
> single specific test session from the SERVER while that test session is
> running?  He doesn’t know what SID the server dynamically allocated to his
> particular test session.
> There are 2 options.  The FIRST 2 paragraphs describe how you can go to
> the CLIENT, retrieve operational data for the test session on the CLIENT
> using the test session NAME – and part of that operational data will be the
> dynamically allocated SID for that session (which the server communicated
> back to the client during the message exchange).  You can then go to the
> server and use that SID as a key to retrieve the individual  record for
> that test session’s operational data on the server.
> IF you have no access to the client, then you’re screwed, because you
> don’t know the dynamically allocated SID for your session’s name, and you
> can’t go to the client and get it. So all you can do is effectively do a
> get/get next of ALL the operational data records for all test sessions
> currently  in progress on the server, and then try to locate the session
> you actually wanted to look at, based on other information (e.g. IP
> addresses, UDP ports, etc) to identify it.  And this may be *problematic
> if a large number of test sessions are currently active on that *(server)
> * device*.  Because you might have 3000 active sessions on that server
> device and now you’re going to have to sift through all 3000 returned
> records looking for the one you were actually interested in.
>
> Hope this makes sense!
>

I REALLY appreciate this explanation. I had foolishly assumed that you were
worried about the load on the server device, but you're actually worried
about the load on the user who is LOOKING at the server device. Makes
perfect sense, with your explanation.

If I might make a suggestion (at the "Comment, so do the right thing"
level), perhaps

OLD

NEW

  If the user has no network access to the Control-Client device, then
   the only option is to retrieve all test-session instances from the
   Session-Reflector device, and then pick out specific test-session
   instances of interest to the user. This could be problematic if a large
   number of test sessions are currently active on that device.

would be helpful. But do the right thing, of course. Because that would be
the right thing to do.

Spencer

---

From: "Civil, Ruth" <[email-masked]>
Date: Fri, 6 Apr 2018 11:46:38 +0000

I’m good with that change (as long as someone else does the update to the doc – I’m kind of busy right now).

Cheers,
                Ruth

From: Spencer Dawkins at IETF [mailto:[email-masked]]
Sent: Thursday, April 05, 2018 8:31 PM
To: Mahesh Jethanandani <[email-masked]>
Cc: Brian Trammell <[email-masked]>; Nalini Elkins <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: [**EXTERNAL**] Re: AD Evaluation of draft-ietf-ippm-twamp-yang-06

Hi, Manesh,

On Thu, Apr 5, 2018 at 5:34 PM, Mahesh Jethanandani <[email-masked]<mailto:[email-masked]>> wrote:
Spencer,

On Mar 29, 2018, at 9:45 PM, Mahesh Jethanandani <[email-masked]<mailto:[email-masked]>> wrote:

Hope this makes sense!

I REALLY appreciate this explanation. I had foolishly assumed that you were worried about the load on the server device, but you're actually worried about the load on the user who is LOOKING at the server device. Makes perfect sense, with your explanation.

If I might make a suggestion (at the "Comment, so do the right thing" level), perhaps

OLD

NEW

would be helpful. But do the right thing, of course. Because that would be the right thing to do.

Spencer

---

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 6 Apr 2018 07:27:51 -0700

Ruth,

I will take care of updating the document. 

Mahesh Jethanandani
[email-masked]

> On Apr 6, 2018, at 4:46 AM, Civil, Ruth <[email-masked]> wrote:
> 
> On Thu, Apr 5, 2018 at 5:34 PM, Mahesh Jethanandani <[email-masked]> wrote:
> Spencer,
>