perfsonar development work

["Michael Bischoff" <>]

Hello all,

I'm in the same boat as Maciej is.

So for my two cents:

I'm going to suggest something that's in line with the suggestion I made with 
the
'Perfsonar-as-a-control-channel', where it also needs to negotiate a couple 
of things like
type of encryption, tunnel protocol etc. Now there the relationship is a bit 
different as is
(in my opinion) with LS. Where at the 'Perfsonar-as-a-control-channel' one 
needs a common
denominator(something both sides it is a little different with the LS as one 
can simply make
the LS have the final 'word'; this way you don't need to have a sequence of 
request -
response pairs and the complexity that it imposes. It also seems odd to make 
the registration
fail over a wrong TTL value.

In practice how it works is that the LS takes the registrar suggestion under 
advisement and
simply picks the closest value that it supports:

So for a LS supporting TTL of 100-500, the following would happen in the 
situations
highlighed by Maciej:


> 2a) LS: no, ttl is too low
(or in this case for <100)
The LS response simply with '100' and the client needs to take the 
appropriate steps.

> or 2b) LS: no, ttl is too high
(or in this case for >500)
The LS response simply with '500' and the client needs to take the 
appropriate steps.

> or 2c) LS: registration successful
(or in this case for x in >100 and <500)
The LS response simply with 'x' confirming that the request was accepted.

This way we keep:
- the number of requests down
- the logic/complexity required down

The only objection I see would be in the case of the LS only supporting high 
TTL values and
it's common that the service 'goes away' (thus leading to a lot of requests 
going nowhere)
But in practice this problem shouldn't really be a problem since: a LS 
implementation
probably favours discarding information as quickly as possible and also if we 
factor in
'locality' the ones affected the most will be the ones who also maintain the 
service/LS.

Just a suggestion,

Kind regards,

Michael

> Guys,
>
>
> As you probably know, I am not officialy working on perfSONAR any more,
> however I will try to support Slawek in his further development of the LS.
>
> The parameters negotiation will certainly need some more "negotiation"
> on one of next meeting. I know there is a need of global solution for such 
> a negotiation
> process for all services (especially MP), however we can still implement 
> something very
> simple what can be the "part" of the future solution.
>
> For me it seems keeping it simple will be the best way of implementing
> it for now:
>
> 1)  Service: register me with TTL 300 sec
>
>
> 2a) LS: no, ttl is too low
> or 2b) LS: no, ttl is too high
> or 2c) LS: registration successful
>
>
> 2a and 2b will need, as Slawek wrote, next registration. Of course if
> much data is sent, it won't be optimal, but implementing stateful sessions 
> will not be
> possible easily now.
>
> Jeff, I fully agree, the response from the LS should be
> machine-parsable. Can you or Jason propose the format? Perhaps you already 
> have something for
> psPS?
>
> Best regards
> Maciej
>
>
>
> Slawomir Trzaszczka wrote:
>
>> Hi Jeff,
>>
>>
>> I have no idea about response (with rejected parameter information)
>> message format. I think that parameter negotiation should be very easy.
>>
>> Client send request to  service (e.g. LookupService). Sent message has
>> parameters (e.g. lsTTL parameter). If the parameters are incorrect, 
>> message will be
>> processed but parameter will be rejected. Response message will have to 
>> contain information
>> about parameters mistake (e.g. out-of-bound) and information about this 
>> parameter
>> limitation (correct value). If the client will want to send new parameter, 
>> he will send
>> registration message with new (improved) parameter to service. Correct 
>> parameter will be
>> accepted and information about it will be send to the client (parameter 
>> accepted).
>>
>>
>> thanks, Slawek.
>>
>>
>>
>> On Thu, 2009-07-02 at 10:03 -0600, Jeff W.Boote wrote:
>>
>>> Hi Slawek,
>>>
>>>
>>> A few of us have been discussing this and would like some more time to
>>> think about the implications.
>>>
>>> Specifically, one concern is that this might really be another case of
>>> needing session state in the protocal. (i.e. the ability to do some 
>>> negotiation between
>>> the client/service.) If so, this is not too different from what will be 
>>> needed to
>>> negotiate a future execute schedule or other parameters in the MP case. 
>>> In which case,
>>> from a protocol perspective I would want these kinds of things handled in 
>>> the same (or at
>>> least similar) way - not as a series of one-off's added when each 
>>> individual developer
>>> decides they need this kind of feature.
>>>
>>> Do you have some thoughts as to how the method you have suggested
>>> below would be applicable to other 'negotiation' types of use cases?
>>>
>>> One suggestion I have regarding your proposal, is that not enough
>>> information is returned that is easily machine-par-sable. Specifically, 
>>> you have the upper
>>> limit in the human-readable part. But not as part of a defined data type 
>>> that a service
>>> could reasonably decode and make a different decision without human 
>>> intervention.
>>>
>>> thanks, jeff
>>>
>>> On Jun 25, 2009, at 1:16 AM, Slawomir Trzaszczka wrote:
>>>
>>>
>>>> Hi all,
>>>>
>>>>
>>>> I'm working on lookup service. I would like to ask you few questions
>>>> about lsTTL parameter and nmwg message form. I'm implementing lsTTL 
>>>> parameter handling
>>>> by lookup service.
>>>>
>>>> New feature is used when a service wants to register to lookup service
>>>> and send lsTTL parameter.
>>>>
>>>> LsTTL (TTL - time to live) parameter is used when the lookup service
>>>> cleans up old services. Latest Lookup Service implementation uses global 
>>>> lsTTL for all
>>>> services registered in database. In new version, service which want to 
>>>> register to
>>>> lookup service, can send own lsTTL parameter. This parameter will be 
>>>> prevented and it
>>>> will ignore global lsTTL.
>>>>
>>>> Message from service, with lsTTL parameter:
>>>>
>>>>
>>>> <message type="LSRegisterRequest">
>>>> <parameters id="parameters.1">
>>>> <parameter name="lsTTL">300</parameter>
>>>> </parameters>
>>>>
>>>>
>>>> <!-- ... -->
>>>> </message>
>>>>
>>>>
>>>>
>>>> The problem is how can lookup service inform client that sent lsTTL
>>>> parameter is accepted/rejected(incorrect,out of bound) - in which part 
>>>> of nmwg message?
>>>>
>>>> This is my proposal :
>>>>
>>>>
>>>>
>>>> <nmwg:metadata id="M_E_T_A_1">
>>>> ...
>>>> </nmwg:metadata>
>>>>
>>>>
>>>> <nmwg:data id="result-code-description" metadataIdRef="M_E_T_A_1">
>>>>
>>>>
>>>> <nmwgr:datum xmlns:nmwgr="http://ggf.org/ns/nmwg/result/2.0/";>
>>>> Data has been registered with key ...
>>>> </nmwgr:datum>
>>>>
>>>>
>>>> </nmwg:data>
>>>>
>>>>
>>>> <nmwg:metadata id="result-code1">
>>>> <nmwg:subject id="reference-to-metadata"
>>>> metadataIdRef="M_E_T_A_1"/>
>>>>
>>>> <nmwg:eventType>
>>>> http://ggf.org/ns/nmwg/result/2.0/warinig/ls/ttl_out_of_bound
>>>> </nmwg:eventType>
>>>>
>>>>
>>>> </nmwg:metadata>
>>>>
>>>>
>>>> <nmwg:data id="result-code-description1"  metadataIdRef="result-
>>>> code1"> <nmwgr:datum>
>>>> Miminimal TTL is 90 sec. Your was 80 sec.
>>>> </nmwgr:datum>
>>>> </nmwg:data>
>>>>
>>>>
>>>> What do you think about this response ? Is it correct ?
>>>>
>>>>
>>>> Regards Slawek
>>>>
>
>
> --
>
>
> --------------------------------------------------------------------
> | Maciej Glowiak        Network Research and Development            ||
> | 
> 
>      Poznan Supercomputing and Networking Center ||
> | (+48 61) 858 2024        -- skype_id: maciej_psnc  -- GG: 4526858 ||
> |                          -- jabber:   
> 
>     ||
> ====================================================================
>
>