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

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 11 Oct 2005 15:10:16 +0100

hi georgios,

> -----Original Message-----
> From: Georgios Karagiannis [mailto:[email-masked]] 
> Sent: 11 October 2005 15:06
> To: Hancock, Robert; Martin Stiemerling
> Cc: [email-masked]; nsis
> Subject: Re: [NSIS] NSLP-Data in intial GIST-Query
> 
> 
> Hi Robert
> 
> I think that you are right!
> Please see inline!
> 
> ----- Original Message ----- 
> From: "Hancock, Robert" <[email-masked]>
> To: "Georgios Karagiannis" <[email-masked]>; "Martin 
> Stiemerling" 
> <[email-masked]>
> Cc: <[email-masked]>; "nsis" <[email-masked]>
> Sent: Tuesday, October 11, 2005 3:13 PM
> Subject: RE: [NSIS] NSLP-Data in intial GIST-Query
> 
> 
> > hi all,
> >
> > there will be a separate answer to Martin's original point
> > (in fact, in an answer to Thomas's answer ...). But there are
> > some specific points here too. Inline:
> >
> >> -----Original Message-----
> >> From: Georgios Karagiannis [mailto:[email-masked]]
> >> Sent: 11 October 2005 10:07
> >> To: Martin Stiemerling; Hancock, Robert
> >> Cc: nsis; [email-masked]
> >> Subject: Re: [NSIS] NSLP-Data in intial GIST-Query
> >>
> >>
> >> 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.
> >
> > In the discovery phase (if discovery is happening), the Querying
> > node *has* to create state at the start; the Responding node
> > can do so in a delayed way (as we all know).
> >
> >>
> >> 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.
> >
> > This is true.
> >
> >>
> >> 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!
> >
> > This is not quite true.
> 
> Georgios: What do you mean?

I mean: it will keep retransmitting the Query if there is no stateful
node
further downstream.

> 
> >>
> >> 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.
> >
> > This is definitely not true. The situation is described in 4.3.2:
> > a GIST node which is stateless in this way will forward the Query
> > downstream, possibly with a revised payload; when this hits 
> a stateful
> > node, the Response will come back. The stateless node MUST NOT send
> > anything back saying 'I am stateless' because then the Querying node
> > would see two (or in general 1+N) replies to its message, 
> all but one
> > of them being failures. The querying node doesn't care about the
> > existence of the stateless nodes anyway (at the GIST level).
> 
> Georgios: You are right!
> 
> > If the Query is lost before it gets to the stateful Responder, or
> > if the Response is lost on the way back, or if there is no stateful
> > Responder in the first place, the original Query will be resent.
> >
> Georgios: But what happens if after the GIST quering node
> there is no statefull node in the whole end to end path?
> The GIST  quering node will keep retransmitting the GIST QUERY or?

It will keep retransmitting until it decides to give up. See 
section 5.3.3 (esp. the second paragraph).

robert h.

> 
> 
> Best Regards,
> Georgios
> 
> 
> 
> >
> >>
> >> 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
> >> >
> >>
> >>
> >
> > _______________________________________________
> > nsis mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/nsis
> > 
> 
> 

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

---

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 12 Oct 2005 18:58:07 +0100

Hi Martin,

thanks for the review. I've added
http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue74
to cover the proposed clarification in section 6.

Is more needed?

robert h.

> From: Martin Stiemerling [mailto:[email-masked]] 
> Sent: 12 October 2005 10:29
> To: Hancock, Robert; Thomas Herzog; Georgios Karagiannis
> 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
>