Subject: [NSIS] GIST: NSLP data in QUERY

From: Jukka MJ Manner <[email-masked]>
Date: Thu, 22 Mar 2007 23:19:34 +0200 (EET)

I've been thinking about how GIST uses the Q-mode. If an NSLP asks for 
reliable or secure mode, GIST will send the query without NSLP payload. 
Yet, would it be possible to still allow an NSLP to include information 
carried in the query.

There does not seem to be any protocol issues, rather it would be an API 
issue: allow an NSLP to indicate data that is carried in the query. This 
data is passed on the receiving node to the NSLP and GIST just forgets 
about it (same as if the sending node would have asked for unreliable and 
unsecure mode).

The benefit is that the receiving NSLP can be given more information than 
simply the MRI and NSLP ID to make the decision on whether it wants to 
peer with the sending node or not.

Jukka

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

---

From: Roland Bless <[email-masked]>
Date: Fri, 23 Mar 2007 09:54:39 +0100

Hi Jukka,

> Yet, would it be possible to still allow an NSLP to include information 

If the semantics for this data is different, yes.

> about it (same as if the sending node would have asked for unreliable and 

Yep. Indeed the API must be changed in order to
indicate what should be passed as "Early-Data" since the
transport semantics are different (unreliable/unprotected)
than for the rest of the data.

> peer with the sending node or not.

This could be useful for several things (esp. connection acceptance policy).
However, we have two restrictions here:
- NSLP Data must fit into one (UDP) datagram
- retransmissions of this portion of data must be performed by the
  NSLP itself.

Regards,
 Roland

---

From: Jukka MJ Manner <[email-masked]>
Date: Fri, 23 Mar 2007 11:00:11 +0200 (EET)

Hi Roland,

> If the semantics for this data is different, yes.

It can be different, or copies of certain NSLP objects. GIST doesn't need 
to care anyway, it's just a feature of NSLPs.

> than for the rest of the data.

That sounds good to me.

> - retransmissions of this portion of data must be performed by the

Yes, good points.

Jukka

---

From: Christian Dickmann <[email-masked]>
Date: Fri, 23 Mar 2007 23:59:33 +0100

Hi Jukka,

> peer with the sending node or not.

 From my point of view, GIST should not allow such a feature. While I 
understand your NSLP-centric reasons, I see one big problem: The NSLP 
does not even know when GIST sends a Query! So how would this work anyway?
And whenever the NSLP creates a new session, why not send one unreliable 
message first and then the secure (or reliable) one?

Thus, could you please clarify how you expect the API to change to 
enable the feature you desire and why this is better than sending one 
unreliable message from the NSLP first?

Regards,
Christian

---

From: Jukka MJ Manner <[email-masked]>
Date: Sat, 24 Mar 2007 19:28:00 +0200 (EET)

First of all, you don't need to provide this extra information, if your 
NSLP doesn't ned it for peering decisions.

Second, you can provide it every time you don't have a SII-Handle for the 
session. If GIST has already an MA for the session, the extra information 
is not used. If no MA is present, GIST will include the extra piece of 
information in the QUERY.

This is much simpler that creating some wierd NSLP-level initial peering 
message handshake, after which you can actually send the meaningful data 
message.

Jukka

On Fri, 23 Mar 2007, Christian Dickmann wrote:

> > reliable or secure mode, GIST will send the query without NSLP payload. Yet,
> > would it be possible to still allow an NSLP to include information carried
> > in the query.
> >
> > data is passed on the receiving node to the NSLP and GIST just forgets about
> > it (same as if the sending node would have asked for unreliable and unsecure
> > mode).
> >
> > simply the MRI and NSLP ID to make the decision on whether it wants to peer
> > with the sending node or not.
> >   
> 
> understand your NSLP-centric reasons, I see one big problem: The NSLP does not
> even know when GIST sends a Query! So how would this work anyway?
> Thus, could you please clarify how you expect the API to change to enable the
> feature you desire and why this is better than sending one unreliable message
> from the NSLP first?
> 
> Regards,
> Christian
> 
>

---

From: Roland Bless <[email-masked]>
Date: Wed, 28 Mar 2007 09:58:36 +0200

Hi,

> to care anyway, it's just a feature of NSLPs.

I meant the transport semantics, e.g. reliable/unreliable transport
of this NSLP data. So the NSLP would transfer a first data chunk
unreliably/unsecured in the Query and after the handshake then
reliable...
So this first data chunk has different semantics within NSLP than
the other NSLP data that follow and this must be made explicitly
visible at the API. That was my point.

Regards,
 Roland

---

From: Jukka MJ Manner <[email-masked]>
Date: Wed, 28 Mar 2007 12:31:45 +0300 (EEST)

Hi,
Yes, good point.

Yet... on the other hand, if you don't get a QUERY through, then you won't 
get to set up an MA anyway, so basically the extra data is also sent in a 
reliable way. But it is not secured.

Jukka

---

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 28 Mar 2007 12:59:23 +0100

hi all,

it's good to keep working through this, because there are several
subtleties. but i think the current design and API handles nearly 
everything i have seen mentioned so far. the main points are more NSLP 
(or, in fact, signalling application) design issues rather than GIST 
issues.

specifically:

- a signalling application has to define the algorithm that it uses
when deciding whether to peer. if the algorithm is 'always true'
then there is nothing else to do. if the algorithm depends on
information
beyond the information in the MRI/SID/NSLPID then this information has
to be defined as part of the NSLP specification.

- almost by definition, this information cannot need security 
protection from GIST, because that is only possible after peering.
(if security protection is needed, that would have to be done in 
the NLSP itself; or else one needs something much more complex,
probably involving multiple NSLPIDs.)

- so far as reliability is concerned, again this is more a matter of
NSLP design. if one is probing for a peer, the response from the peer
indicates that the original message was delivered. if you get no
response within some timeout, there is no peer to respond. the NSLP
needs to make sure that it doesn't retransmit within the validity
time it provides with the message (since the GIST level can retransmit
Queries during this period). the more important thing to note is that
the NSLP payload can be delivered multiple times, so it needs to be
idempotent.

- the API already provides the hooks to express reliability and
security requirements. so, for a probing message, you just leave these
unset.

- and the API also allows the NSLP to be aware of the routing status:
at the querying node the fact that there is no SII means that no
routing state exists; at the responding node, the fact that this is
done with the routing state check flag set in RecvMessage means that
this decision is being made.

- another issue is how the NSLP influences the refresh of this
conditional peering. GIST handles making sure that the routing state
as defined by the MRM is up to date, but if there is NSLP-dependent
information that should be used in the peering decision that will not
be taken care of. OTOH, the timescales over which MRM-related state
and NSLP-related state might need to be checked can be quite
independent,
so I don't think there is a need to extend the definition of normal GIST
routing state refresh to cover this. if the NSLP really does want to
check that the NSLP-dependent peering is still valid, it can always
force a refresh with the InvalidateState call. This will start a 
refresh at some point in the future.

- what is slightly messy is that the NSLP would have to do Invalidate
and then SendMessage to provide the NSLP data for the Query payload,
so there are API-internal race conditions. One could regard this as
just an implementation issue; another possibility would be to extend
Invalidate with the option to provide an NSLP payload and associated
fields (excluding transfer attributes, since they must be null).

i created
http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue213
to cover this specific point.

r.

> -----Original Message-----
> From: Jukka MJ Manner [mailto:[email-masked]] 
> Sent: 28 March 2007 10:32
> To: Roland Bless
> Cc: NSIS Working Group; Hancock, Robert
> Subject: Re: [NSIS] GIST: NSLP data in QUERY
> 
> 
> Hi,
> Yes, good point.
> 
> Yet... on the other hand, if you don't get a QUERY through, 
> then you won't get to set up an MA anyway, so basically the 
> extra data is also sent in a reliable way. But it is not secured.
> 
> Jukka
> 
> > >>> I've been thinking about how GIST uses the Q-mode. If 
> an NSLP asks 
> > >>> for reliable or secure mode, GIST will send the query 
> without NSLP payload.
> > >>> Yet, would it be possible to still allow an NSLP to include 
> > >>> information carried in the query.
> > > It can be different, or copies of certain NSLP objects. 
> GIST doesn't 
> > > need to care anyway, it's just a feature of NSLPs.
> > 
> > I meant the transport semantics, e.g. reliable/unreliable 
> transport of 
> > this NSLP data. So the NSLP would transfer a first data chunk 
> > So this first data chunk has different semantics within 
> NSLP than the 
> > other NSLP data that follow and this must be made 
> explicitly visible 
> > at the API. That was my point.
> > 
> > Regards,
> >  Roland
> > 
> > 
>