Subject: RE: [NSIS] GIST section 4.3.2, adjacency-check

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 26 Oct 2005 14:42:04 +0100

hi roland, thomas,

i can provide some general and specific clarifications.

1) "adjacent" = "having explicit routing state towards"; the key point
is about routing state, not messaging associations. signalling 
applications care about being adjacent or not, but don't care about
messaging associations. (MAs can only be set up between adjacent peers,
but this is logically subordinate to the adjacency, which is the primary
concept.)

2) routing state is managed entirely by GIST handshake operations. so,
the key message is the Query - you have to accept Responses to your own
Queries, and have to accept Responses to your own Confirms. So, the 
choice is made during the processing of the initial Query.

3) the adjecency check that GIST makes with the NSLP is performed
*within* the processing of the Query message, i.e. during the 
processing GIST will at some point call RecvMessage and will expect
a return value which tells it what to do. it then sends a Response
for re-forwards the Query as appropriate. There is no separate
SendMessage call from the NSLP to do this.

some further detailed comments in line,

r.

> -----Original Message-----
> From: Roland Bless [mailto:[email-masked]] 
> Sent: 25 October 2005 15:34
> To: Thomas Herzog
> Cc: [email-masked]; Hancock, Robert
> Subject: Re: [NSIS] GIST section 4.3.2, adjacency-check
> 
> 
> Hi Thomas,
> 
> I think section 4.3.2 needs definitely some clarifications.
> 
> >>   Even when a message relates to a local signaling application, an
> >>   adjacency MAY be required based on signaling application 
> policy, and
> >>   the application of this policy MAY depend on the NSLP payload.
> >>   Therefore, when this decision has to be made, the NSLP payload is
> >>   delivered and the signaling application has two options:
> >>
> >>   o  to proceed setting up the adjacency.  The application 
> MAY provide
> >>      an NSLP payload (which will be used in any GIST-Response).
> >>
> >>   o  to bypass the message and drop out of the signaling path.  The
> >>      application MAY provide an updated NSLP payload (which will be
> >>      used in the message which is then forwarded by GIST).
> > 
> > 
> > As the GIST API defines a "adjacency check" flag in 
> RecvMessage, I suppose, 
> > GIST must indicate the request of a Messaging Association 
> ("adjacency"?!?!) 
>                                       
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> At least the terminology section doesn't state that Adjacency means or
> is identical to an MA between two peers. IMHO it only defines that two
> GIST nodes are directly adjacent with respect to GIST and NSLP.
> If I understood the  Adjacency Check mechanism correctly it allows an
> NSLP to act as a bypass if it is not interested in the exchange.

yep.

> 
> A little bit confusing is the fact that section 4.3.2 doesn't
> specify exactly the message which may request the setup of an 
> adjacency.
> Is there a difference if it is a GIST-Query, GIST-Confirm, 
> GIST-Response
> or GIST-Data (maybe even received via an existing MA).

see above (i hope).

> 
> Again in more detail:
> >>   Even when a message relates to a local signaling application, an
> >>   adjacency MAY be required based on signaling application policy,
> 
> "an adjacency": is it an adjacency with the Querying upstream node?
> Could it be a different adjacency with another third node?

with the upstream node.

> 
> >>   o  to proceed setting up the adjacency.  The application 
> MAY provide
> >>      an NSLP payload (which will be used in any GIST-Response).
> 
> So an adjacency can only be setup by a GIST-Query? What is the
> reaction of the local node? Does it send a GIST-Response back
> in this case or why says the above sentence "_any_ GIST-Response"?

the *any* refers to the fact that there may instead be a GIST-Error,
or retransmitted Responses, etc.

> 
> >>   o  to bypass the message and drop out of the signaling path.  The
> >>      application MAY provide an updated NSLP payload (which will be
> >>      used in the message which is then forwarded by GIST).
> 
> I assume that it should mean: the original message type with 
> the updated
> NSLP payload is forwarded further down the path, i.e. in this case no
> GIST-Response is generated.

yes - and the original message is a Query.

> 
> > This raises some problems in my eyes:
> > 
> > - When late state setup is used,  GIST does not save any 
> state where it later 
> > could check if a Message Association is rightly established 
> (it will be 
> > established on receipt of a GIST Confirm). Only possibility 
> would be to send 
> > no Stack Proposal in the Response. However, some local 
> state must be 
> > established on Query receipt for asynchronously asking the 
> NSLP via the 
> > API?!?!
> 
> So you mean some temporary local state until the NSLP has
> given an answer and a corresponding GIST-Response
> is created and sent back? This may be negligible because
> you would need some resources for processing a Query anyway.
> It is however important that no state is kept after the
> Response is sent.

i hope this is explained by point (3) above.

> 
> > - When a message association is to be set up, the GIST 
> Querier does generally 
> > not include NSLP payload in the Query at all, because it 
> gets queued until 
> > the Association is set up (NSLP could have required 
> 'reliable' or 'secure' 
> > for the data). So GIST has no data to deliver to the NSLP 
> when it asks if the 
> > association should be set up. It would in general only 
> deliver "shall I 
> > associate", the MRI, the Session ID and the NSLPID...
> 
> This is related somewhat to the problem mentioned in the thread
> "NSLP-Data in intial GIST-Query" and
> http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue74

you can easily imagine some initial data which does some capability
discovery at the NSLP level (which might not need to be sent 
securely). in any case, this is a matter of NSLP design.

> 
> > Or is this section to be understood in a more general way? 
> Is this "adjacency" 
> > simply about setting up routing state in general?
> 
> I think it is not clearly defined in the draft what "setting up
> an adjacency" really means...
> 
> Regards,
>  Roland
> 

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

---

From: Thomas Herzog <[email-masked]>
Date: Wed, 26 Oct 2005 18:43:24 +0200

Hi, Robert,

You input made it all clearer, but maybe the first paragraphs auf 4.3.2 need 
some alteration to make it clear that: 

"When the initial GIST-Query is received, GIST checks with the appropriate 
NSLP if routing state towards the Q-Node should be established. This is done 
by calling the RecvMessage primitive with Adjacency-Check flag set. GIST then 
interprets the Return value to carry out what the NSLP has decided. This can 
be:
- ...
- ..."

The other irritations I had were caused by the fact that I did not recognize 
that the RecvMessage call is in fact a synchronous function call (with a 
return value). As we are implementing the API via Messages (over a UNIX 
domain socket), this implies some modifications to our implementation 
specific state machine.

But besides implementation specific issues, there is still one little quirk in 
the draft:

- GIST calls RecvMessage with the Adjacency-Flag set, the Return value is 
inspected so it will either send a response or relay the message.

This is done synchronously via the API primitive.

- The NSLP MAY provide altered data payload in both cases

How is THAT to be done? Is the FIRST SendMessage from the NSLP carrying that 
data? Is it defined in NSLP drafts, that there MUST be a SendMessage after a 
RecvMessage with Adjacency-Check flag set?

Furthermore, if GIST inspected the return code of the RecvMessage call, it 
would still have to wait for Data to include?

How long would it wait? What if NSLP wants to include NO UPDATED data? Will it 
pass a SendMessage anyway, even with the old data?

Or should there be MORE return values to RecvMessage? 
e.g. "relay"/"relay - data following"/"setup state"/"setup state - data 
following"? The return values are not defined further in the draft.

This also seems to require a "temporary" state for the R-Node state machine: 
"awaiting replaced data"  which will be destroyed if the action (send back 
response or relay query, go to awaiting-confirm or dead afterwards) has been 
performed.

This requirement seems not to be implementation specific, SendMessage is an 
asynchronous primitive after all.

Cheers,
Thomas

Am Mittwoch, 26. Oktober 2005 17:29 schrieben Sie:
> hi,
>
> i've added this as
> http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue100
>
> will either/both of you be in vancouver? it might be good to have
> a review of the next version (which i will probably do during the
> meeting ...) to find out whether particular parts are clearer.
>
> cheers,
>
> r.
>
> > From: [email-masked] [mailto:[email-masked]] On
> > Behalf Of Hancock, Robert
> > Sent: 26 October 2005 14:42
> > To: Roland Bless; Thomas Herzog
> > Cc: [email-masked]
> > Subject: RE: [NSIS] GIST section 4.3.2, adjacency-check
> >
> >
> > hi roland, thomas,
> >
> > > >>   Even when a message relates to a local signaling
> >
> > application, an
> >
> > > >>   Therefore, when this decision has to be made, the NSLP
> >
> > payload is
> >
> > > >>   o  to bypass the message and drop out of the signaling
> >
> > path.  The
> >
> > > >>      application MAY provide an updated NSLP payload
> >
> > (which will be
> >
> > > At least the terminology section doesn't state that
> >
> > Adjacency means or
> >
> > > is identical to an MA between two peers. IMHO it only
> >
> > defines that two
> >
> > > If I understood the  Adjacency Check mechanism correctly it
> >
> > allows an
> >
> > > >>   Even when a message relates to a local signaling
> >
> > application, an
> >
> > > >>   adjacency MAY be required based on signaling
> >
> > application policy,
> >
> > > >>   o  to bypass the message and drop out of the signaling
> >
> > path.  The
> >
> > > >>      application MAY provide an updated NSLP payload
> >
> > (which will be
> >
> > > NSLP payload is forwarded further down the path, i.e. in
> >
> > this case no
> >

---

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 28 Oct 2005 11:32:40 +0100

Hi Thomas,

I'll add the need for some more clarification on the synchronous
nature of the check to 4.3.2 under issue 100.

In terms of how the updated payload is provided, i think the minimal
requirement on an NSIS implementation is that it is done synchronously
as part of the processing of the Query message. To define what 
'synchronously' means more precisely is hard to do without going
into implementation issues, or at least API issues. My assumption
is that the easiest way to do this is for the return value from the
NSLP to provide a pointer to the result and the updated payload; 
another way (if the NSLP and GIST are in the same process or at least
able to share memory) is for the Payload argument provided by 
GIST in the RecvMessage call to be mutable and to contain the updated
payload when the call returns. Having the application call SendMessage
synchronously is another possibility, but I would say less attractive
from an implementation perspective for at least the reasons you
give below. Other reasons are that GIST has to correlate the two
calls and to realise that the SendMessage does not lead to a new
Query but a modified payload for a 'pending' one, and that the usage
of SendMessage has to be very restricted (e.g. can't set the transfer
attributes, or freely choose the GHC or IP TTL and so on). I think it
would be possible to add some description along these lines to the
API sections.

cheers,

robert h.

> From: Thomas Herzog [mailto:[email-masked]] 
> Sent: 26 October 2005 17:43
> To: Hancock, Robert
> Cc: [email-masked]