RE: [NSIS] About GIMPS!

["Hancock, Robert" <[e-mail]>]

dear all,

if people want to see the reasoning which went into the current
framework split, it is still written down in
http://www.watersprings.org/pub/id/draft-hancock-nsis-sender-receiver-00.txt

the essential points are:
a) does a protocol have any asymmetry in operation (i.e. client/server,
initiator/responder, whatever)
b) if so, does that asymmetry have any coupling to the direction of
the data flow

the argument of the above i-d (reflected in the framework and the
subsequent protocol designs) is that these questions have to be
considered independently for the NTLP (GIMPS) and NSLPs (signalling
applications).

Specifically for GIMPS, there is asymmetry in the discovery phase,
because only the upstream node can initiate the process (that's a
consequence of IP routing) as Cheng says below. (Whether you want
to call this sender or receiver initiated is just a terminology
issue.) If we can think of ways to make discovery possible in both
directions, we might incorporate them. However, once the message
routing state is set up, GIMPS tries as hard as possible to hide
this asymmetry from the signalling applications. They can make their
own decisions about whether aspects of their protocol should be 
directional and whether to tie that to data flow direction.

What is definitely the case is that GIMPS punts on what initiates the
discovery process in the first place. This is a trigger from the
OS or a particular signalling application, or network management,
or whatever. Signalling application developers need to say what
kicks off this part of the process.

Does this answer the question?

r.

> -----Original Message-----
> From: Cheng Hong [mailto:[e-mail]]
> Sent: Wednesday, April 07, 2004 03:52
> To: 'Tschofenig Hannes'; 'Elena Scialpi'; 'nsis'
> Subject: RE: [NSIS] About GIMPS!
> 
> 
> Hi Hannes,
> 
> 
> <Snip>
> > if you decouple the authorization aspects from the signaling 
> > aspects then
> > the concepts of sender- vs. receiver-initiated "something" 
> > are less obvious
> > in a path-coupled signaling protocol. i personally think that the
> 
> I think if we further decouple the messaging association establishing
> procedure (GIMPS) from the actual signaling (NSLP signaling), the
> sender-init vs. receiver-init would be less important. With 
> the current text
> in GIMPS, there is still a subtle difference, e.g. in D-mode, 
> sender-init
> could send NSLP message with the "GIMPS-query" message. 
> 
> As for the messaging association establishment, it is a GIMPS level
> signaling. According to the text in section 4.3, it has to be 
> initiated from
> upstream. What is lacking is how this process is triggered 
> (maybe out of
> scope). What I am not so sure is that if it is triggered by a 
> message sent
> by the receiver, e.g. a BU from a MN, could we call it 
> receiver initiated?
> 
> 
> > definitions of these two terms is rather fuzzy (even in the 
> > framework). with
> > path-coupled signaling only the sender is able to start signaling.
> 
> Do you mean the GIMPS signaling described above? I feel it 
> depends on what
> we took as "signaling": NSLP or NSLP+NTLP. But, overall (for 
> NTLP and NSLP),
> it is quite true.
> 
> 
> cheers
> 
> Cheng Hong 
> 
> 
> > 'maintaining the treatment for a flow' is also difficult to 
> > understand in
> > the light of our mobility discussions or the recently 
> > discussed preemption
> > issues. 
> > 
> > ciao
> > hannes
> > 
> > 
> > > 
> > > Thanks for your replies,
> > > Elena
> > >  
> > > 
> > > 
> > > _______________________________________________
> > > nsis mailing list
> > > [e-mail]
> > > https://www1.ietf.org/mailman/listinfo/nsis
> > > 
> > 
> > _______________________________________________
> > nsis mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/nsis
> > 
> > 
> 
> 
> 
> _______________________________________________
> nsis mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/nsis
> 

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