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

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 11 Oct 2005 14:50:51 +0100

Hi Thomas, Martin, all,

I think I claim that the answers to these questions are in the 
specification, but that you have to read very carefully to find
them. In particular, more detail could be added to 4.3.2 and/or
6 and/or B.2 to say exactly what is done with the NSLP payloads
under the various circumstances, and perhaps some more examples
(or development of the text in section 3) would also be helpful.

I've tried below to explain what the various answers are; it would
be really good to know if 
- the answers themselves make sense
- what would be the most accessible way to reflect them better
in the specification.

Cheers,

robert h.

ps for some related discussion, see the thread around
http://www.ietf.org/mail-archive/web/nsis/current/msg04765.html

> -----Original Message-----
> From: Thomas Herzog [mailto:[email-masked]] 
> Sent: 11 October 2005 11:54
> To: Georgios Karagiannis
> Cc: Martin Stiemerling; Hancock, Robert; 
> [email-masked]; nsis
> Subject: Re: [NSIS] NSLP-Data in intial GIST-Query
> 
> 
> 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? 

Yes: 4.3.2 indicates, at least to me ;-) that any payload carried
in a GIST message is delivered to the NSLP if the NSLP exists.
This could be made more explicit in 4.3.2 or in 6. I agree it's
a bit awkward that the rules in 6 say what to do with the payload
for some message types but not others, but it gets a bit dull saying
'deliver NSLP payload' in every rule ... i am open to suggestions
about what would be clear.

> 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:

Not the case; see my earlier reply to Georgios.

> 
> 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.

In fact, the issue here is that the rule misses the 'stateless 
handling of a Query' case. I was never sure whether including this
in the state machine description was useful, since (by definition)
it only shows up in the Node state machine for which most of the 
details are in the text in the remainder of the document. But it's
true that the level of detail is not consistent, so maybe that should
be fixed.

> 
> 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.

True. You have to infer it from more general text elsewhere. 
Possibly the 'deliver payload' rule should be added to all message
rules where a payload is possible.

> 
> 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.

The state machines leave it out. The text in 4.3.2 is supposed to 
apply to all message types (but maybe this is not clear).

> 
> 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).

I think (if you are referring to 4.3.2) that the MAY language applies
to what the NSLP is allowed to do. (There are two MAY options; it might
need to be clearer that the NSLP MUST do one or the other.) 
What GIST is allowed to do is (intended to be) more precise: it 
MUST deliver the payload and MUST do what the application indicates 
in 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....

That is not the intention. The basic rule is that GIST only sends
an NSLP payload that an NSLP has provided to it through the API: so, the
payload in the Response must be something provided by the NSLP at the
Responder, or must be absent. The payload in the Confirm must be
a (new) payload provided by the NSLP at the Querying node. (If it
was a repetition of the original payload, than the message sequence
at the NSLP level would start to look very strange.) Coupled with the
rule that the payload is always delivered to the NSLP, I think this
answers Martin's original question, i.e.:
- if the Responding node NSLP decided to drop the payload, it 
can indicate this in the payload in the Response. It's then up to
the Q-node NSLP to decide whether to generate another payload or
resend the original one. That payload might get carried in the 
Confirm or a later message.
- if the Responding node NSLP decided to keep the payload, it can
also indicate this in the payload in the Response. The Q-Node
NSLP can then move to the next stage in the transaction.

Whether the retransmitted Query should include the payload is left
open. Strictly it shouldn't matter either way: the payload must have
been sent with the unreliable transfer attribute, in which case 
applications must be prepared for it to be delivered 0/1/many times.
I think it would typically be reasonable for a node to include
the payload in retransmissions, but I'd be interested to see if
people thought that behaviour was a MUST.

> 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?!?!?)

Strictly yes: it's all unreliable. But I think that would count as
a low-quality implementation.

cheers,

robert h.

> 
> Cheers,
> Thomas
> 
> 
> 
> Georgios Karagiannis wrote:
> > 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 
> >> 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: Martin Stiemerling <[email-masked]>
Date: Wed, 12 Oct 2005 11:28:42 +0200

Hi Robert, all,

--On Dienstag, 11. Oktober 2005 14:50 Uhr +0100 "Hancock, Robert" 
<[email-masked]> wrote:

| Hi Thomas, Martin, all,
|
| I think I claim that the answers to these questions are in the
| specification, but that you have to read very carefully to find
| them. In particular, more detail could be added to 4.3.2 and/or
| 6 and/or B.2 to say exactly what is done with the NSLP payloads
| under the various circumstances, and perhaps some more examples
| (or development of the text in section 3) would also be helpful.

After re-thinking it I do not see any problem anymore, considering
the text in Section 3.5 (point 5.) and Section B.2. Reading this, it is
clear that the NSLP level must take care about the described case
of state setup delay. However, this may require some text in the
NSLP sections describing the inter-working with the NTLP.

|
| I've tried below to explain what the various answers are; it would
| be really good to know if
| - the answers themselves make sense
| - what would be the most accessible way to reflect them better
| in the specification.
|
| Cheers,
|
| robert h.
|
| ps for some related discussion, see the thread around
| http://www.ietf.org/mail-archive/web/nsis/current/msg04765.html
|
|> -----Original Message-----
|> From: Thomas Herzog [mailto:[email-masked]]
|> Sent: 11 October 2005 11:54
|> To: Georgios Karagiannis
|> Cc: Martin Stiemerling; Hancock, Robert;
|> [email-masked]; nsis
|> Subject: Re: [NSIS] NSLP-Data in intial GIST-Query
|>
|>
|> 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?
|
| Yes: 4.3.2 indicates, at least to me ;-) that any payload carried
| in a GIST message is delivered to the NSLP if the NSLP exists.
| This could be made more explicit in 4.3.2 or in 6. I agree it's
| a bit awkward that the rules in 6 say what to do with the payload
| for some message types but not others, but it gets a bit dull saying
| 'deliver NSLP payload' in every rule ... i am open to suggestions
| about what would be clear.

I see the text as being fine. If NSLP-Data is provided as NTLP payload it
is handled over to the particular 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:
|
| Not the case; see my earlier reply to Georgios.
|
|>
|> 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.
|
| In fact, the issue here is that the rule misses the 'stateless
| handling of a Query' case. I was never sure whether including this
| in the state machine description was useful, since (by definition)
| it only shows up in the Node state machine for which most of the
| details are in the text in the remainder of the document. But it's
| true that the level of detail is not consistent, so maybe that should
| be fixed.

Current text is fine since this is stateted in Section 6.3:
" In cases 1 and 3 the R-SM is created already in the Established state."

|
|>
|> 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.
|
| True. You have to infer it from more general text elsewhere.
| Possibly the 'deliver payload' rule should be added to all message
| rules where a payload is possible.

I would suggest a small note before the rules indicating again that
the NTLP passes always a call to the NSLP when receiving a
message, even with a NSLP null payload. Basically repeating the
part out of Section 3.5 (point 5).

With best regards,

  Martin