Subject: Re: [NSIS] About GIMPS!

From: "Thanh Tra LUU" <[email-masked]>
Date: Wed, 7 Apr 2004 16:31:20 +0200

hi Hannes,

the asymmetric routing is mentioned in nsis requirements . so i think it is
clear here.

Is it right that routing record is not used in GIMPS ?

Nary Tra,
ENST, Paris

----- Original Message -----
From: "Tschofenig Hannes" <[email-masked]>
To: "'Thanh Tra LUU'" <[email-masked]>
Cc: "'nsis'" <[email-masked]>
Sent: Wednesday, April 07, 2004 4:04 PM
Subject: RE: [NSIS] About GIMPS!

> hi nary,
>
> with asymmetric routes and path-coupled signaling the first message
> (discovery) needs to be sent from the data sender.
>
> if you would like to send signaling messages back (from the receiver to
the
> sender) along the same path then you need to either
> - establish some information at each intermediate node or
> - do something like record route
> to allow your messages to travel back along the same path.
>
> ciao
> hannes
>
> > 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!
> >
> >
> > > 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
> > >
> >
>

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

---

From: Tschofenig Hannes <[email-masked]>
Date: Wed, 7 Apr 2004 16:04:39 +0200

hi nary, 

if you would like to send signaling messages back (from the receiver to the

ciao
hannes