Subject: [NSIS] NSLP-Data in intial GIST-Query

From: Martin Stiemerling <[email-masked]>
Date: Tue, 11 Oct 2005 10:08:11 +0200

Hi,

GIST-Query messages may carry a NSLP-Data object containing information for 
the NSLP. I'm now assuming an initial GIST-Query send downstream looking 
for the next peer., carrying NSLP-Data, and a GIST downstream node using a 
stateless approach (delayed state setup, using a responder cookie ). In 
this case, the NSLP data would be lost, if not re-transmitted in the 
GIST-Confirm/GIST-Data later, since the downstream peer does not keep any 
state about the initial GIST-Query. There is no text (as far as I know) 
describing what the sending GIST-peer should do in this case. In the case 
of a "stateless" downstream peer (querying node sees response with 
responder cookie and R-flag set), the querying must re-send the NSLP-data 
in the next message.

I may have missed something while reading the draft, but this issue was 
coming to mind afterwards.

With best regards,

  Martin

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 11 Oct 2005 11:07:07 +0200

Hi Martin

I think that your example is not very clear!
Please note that during the discovery phase it is assumed that the
querying and responding node do not have to create the GIST routing state.

Thus your example is valid for both GIST stateless and GIST stateful 
responding nodes.
Please note however, that the sending node will wait for a timeout, and if 
no GIST-Response arrives in time,
then  it will resend the complete GIST QUERY message including the payload.
Please also note that if the GIST responding node receives the GIST_QUERY 
message,
it will send the payload to the appropriate NSLP. Thus even during the first 
GIST-QUERY the NSLP-DATA
will be forwarded to the NSLP.

But anyway, you raised a good point!
The real problem that occurs due to the stateless GIST responding node is 
that the
GIST queying  node will keep retransmiting the GIST-QUERY message!

Therefore, I think that it is needed to specify a way such that the 
stateless GIST responding node
will inform the GIST querying node that the GIST responding node is a 
stateless node.

Best Regards,
Mayi and Georgios

----- Original Message ----- 
From: "Martin Stiemerling" <[email-masked]>
To: "nsis" <[email-masked]>
Sent: Tuesday, October 11, 2005 10:08 AM
Subject: [NSIS] NSLP-Data in intial GIST-Query

> Hi,
>
> GIST-Query messages may carry a NSLP-Data object containing information 
> for the NSLP. I'm now assuming an initial GIST-Query send downstream 
> looking for the next peer., carrying NSLP-Data, and a GIST downstream node 
> using a stateless approach (delayed state setup, using a responder 
> cookie ). In this case, the NSLP data would be lost, if not re-transmitted 
> in the GIST-Confirm/GIST-Data later, since the downstream peer does not 
> keep any state about the initial GIST-Query. There is no text (as far as I 
> know) describing what the sending GIST-peer should do in this case. In the 
> case of a "stateless" downstream peer (querying node sees response with

---

From: Thomas Herzog <[email-masked]>
Date: Tue, 11 Oct 2005 12:54:04 +0200

Hi, Georgios,

I think Martin referred to a stateful responder node which is set up for 
late state installation.
In this case, the responder node will not keep *ANY* state and only 
dispatch a Response which contains the responder cookie and R-flag set 
to request a Confirm. The question now arisen was rather: Would the 
Responder node pass the  NSLP data payload  which MAY be  included  in 
the  Query  to it's NSLP? Let's look at the state machine definitions in 
Draft-08:

For the stateless responder node approach, draft-08 includes a rule in 
the Node State Machine (6.1), that incoming GIST DATA messages should be 
passed to the appropriate NSLP instance, if there is no state associated 
with the message peer:

Rule 4 (rx_Data): pass directly to NSLP

In the case of a stateless responder node, it would in my opinion always 
dispatch at least a response, even if it keeps no state, so the querying 
Node would stop transmitting queries:

Rule 1 (rx_Query):

if (routing state can be created without a full 3-way handshake) then
  create R-SM and pass message to it
else
  send Response

However, maybe one should include here "routing state to be set up and 
this can be created without a full 3-way handshake" in the "if" instruction.

So finally: it is not stated that the POSSIBLE payload in a Query is 
passed to the NSLP instance in the State Machine definitions. Responder 
Node State Machine rules 1 and 5 do not specify that there is something 
to do with included payload in Query Messages.

However, it is allowed to include NSLP data payload in initial GIST 
QUERY and also RESPONSE/CONFIRM messages. The draft does not state what 
to do with this payload in the state machine definitions.

In another section, the draft states, that GIST MAY do this or that 
(check with NSLP in case of ongoing Message Association setup and 
include NSLP data in the response).

A node which is set up stateful and for late state setup could even send 
the NSLP data payload back in the response so the Querying Node could 
include it in the Confirm without remembering it....I think the state 
machine definitions are somewhat lacking to as what to exactly do with 
NSLP data payload in Messages other than GIST DATA. (an implementation 
could even decide to totally ignore NSLP data payload in these Messages 
and not to use it for it's own processing at all?!?!?)

Cheers,
Thomas

Georgios Karagiannis wrote:
> Please note however, that the sending node will wait for a timeout, 
> and if no GIST-Response arrives in time,
> Please also note that if the GIST responding node receives the 
> GIST_QUERY message,
> it will send the payload to the appropriate NSLP. Thus even during the 
> first GIST-QUERY the NSLP-DATA
> The real problem that occurs due to the stateless GIST responding node 
> is that the
> ----- Original Message ----- From: "Martin Stiemerling" 
> <[email-masked]>
>> GIST-Query messages may carry a NSLP-Data object containing 
>> information for the NSLP. I'm now assuming an initial GIST-Query send 
>> downstream looking for the next peer., carrying NSLP-Data, and a GIST 
>> downstream node using a stateless approach (delayed state setup, 
>> using a responder cookie ). In this case, the NSLP data would be 
>> lost, if not re-transmitted in the GIST-Confirm/GIST-Data later, 
>> since the downstream peer does not keep any state about the initial 
>> GIST-Query. There is no text (as far as I know) describing what the 
>> sending GIST-peer should do in this case. In the case of a 
>> "stateless" downstream peer (querying node sees response with 
>> responder cookie and R-flag set), the querying must re-send the 
>> NSLP-data in the next message.
>>
>> I may have missed something while reading the draft, but this issue 
>> was coming to mind afterwards.
>>
>> With best regards,
>>
>>  Martin