Subject: RE: [NSIS] About GIMPS!

From: Tschofenig Hannes <[email-masked]>
Date: Wed, 7 Apr 2004 11:11:15 +0200

hi robert, 

i guess we all agree that there is asymmetry in the discovery phase. 
i only have problems with the "original definition" of sender- vs.
receiver-initiated reservations. the do not fit into the nsis picture. 

ciao
hannes

> -----Original Message-----
> From: Hancock, Robert [mailto:[email-masked]]
> Sent: Wednesday, April 07, 2004 10:49 AM
> To: 'Cheng Hong'; Tschofenig Hannes; 'Elena Scialpi'; 'nsis'
> Subject: RE: [NSIS] About GIMPS!
> 
> 
> 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-r
> eceiver-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:[email-masked]]
> > 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
> > > > [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
> > 
> 
> -- 
> 
> Visit our website at www.roke.co.uk
> 
> Registered Office: Roke Manor Research Ltd, Siemens House, 
> Oldbury, Bracknell,
> Berkshire. RG12 8FZ
> 
> The information contained in this e-mail and any attachments 
> is confidential to
> Roke Manor Research Ltd and must not be passed to any third 
> party without
> permission. This communication is for information only and 
> shall not create or
> change any contractual relationship.
> 

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

---

From: "Thanh Tra LUU" <[email-masked]>
Date: Wed, 7 Apr 2004 13:49:02 +0200

hi Hannes,

i think there is no asymmetric routing here. In the mode receiver-initiator,
the recevier maintains the forward state ( Resv state in RSVP). However, the
sender must discover the data path in anycase and there in only one data
path (sender -> receiver).

Nary Tra,
ENST, Paris.

----- Original Message -----
From: "Tschofenig Hannes" <[email-masked]>
To: "'Hancock, Robert'" <[email-masked]>; "'Cheng Hong'"
<[email-masked]>; "'Elena Scialpi'" <[email-masked]>; "'nsis'"
<[email-masked]>
Sent: Wednesday, April 07, 2004 11:11 AM
Subject: RE: [NSIS] About GIMPS!