RE: [NSIS] Requirement Section 5.3.2

[[e-mail]]

Hi All,

Looking at this requirement from another direction, it seems
that the requirement is really about supporting time-based
reservations.  Is this the real requirement?  If so,
do we support this?

John

> -----Original Message-----
> From: ext Hancock, Robert [mailto:[e-mail]]
> Sent: 15 March, 2002 11:31
> To: 'Georgios Karagiannis (ELN)'; 'Freytsis, Ilya'; '[e-mail]';
> '[e-mail]'
> Subject: RE: [NSIS] Requirement Section 5.3.2
> 
> 
> Georgios,
> 
> Please, let's not mix together the requirements and the 
> solution at this stage! Soft state might be a (or even the) 
> solution, but that doesn't make it a requirement!
> 
> In fact, we have at least three independent state-related 
> requirements to consider:
> 1) the fact that the application wants a bearer of a limited 
> duration (and only wants to pay for this duration) - the end 
> user might want quite precise timing control over this (for 
> accounting reasons)
> 2) the need to clean up after a node dies or becomes 
> disconnected from the network (in which case explicit release 
> isn't possible)
> 3) the need to re-install state after path (route) changes 
> (which might be managed by something routing-aware)
> 
> Soft-state *can* solve all these, but in some scenarios it 
> might be *very* hard to find a good compromise soft-state 
> timer value considering all the effects. Also, in some 
> scenarios (e.g. mobile) it might be better to address some of 
> the problems (e.g. 3) in a different, specialised way. But in 
> that case, it's helpful to have explicitly the requirement 
> that there are other reasons for needing refresh or timeout 
> or explicit release or whatever.
> 
> Personally, I like Ilya's description of the situation. But 
> we could make things less judgemental by saying "it must be 
> possible for an initiator to control reservation reservation 
> end times without requiring continuous signalling with the 
> network" (or something); we can think later whether relying 
> always on soft state or allowing explicit lifetimes is a 
> better solution. I certainly don't see why explicit lifetimes 
> are so hard.
> 
> Robert H.
> 
> > -----Original Message-----
> > From: Georgios Karagiannis (ELN)
> > [mailto:[e-mail]]
> > Sent: 15 March 2002 08:18
> > To: 'Freytsis, Ilya'; '[e-mail]'; '[e-mail]'
> > Subject: RE: [NSIS] Requirement Section 5.3.2
> > 
> > 
> > Hi Ilya
> > 
> > I think that the issue that you are describing can be solved by 
> > the soft state principle.
> > Anyway in my opinion the NSIS protocol MUST use the soft state
> > principle, otherwise we will have to invent very complex 
> > functionalities that will solve all the problems that are solved by 
> > the soft state principle.
> > 
> > Best Regards,
> > Georgios
> > 
> > 
> > 
> > -----Original Message-----
> > From: Freytsis, Ilya [mailto:[e-mail]]
> > Sent: vrijdag 15 maart 2002 4:57
> > To: '[e-mail]'; '[e-mail]';
> > '[e-mail]'
> > Subject: RE: [NSIS] Requirement Section 5.3.2
> > 
> > 
> > Hi Georgios,
> > 
> > Let me present another argument in support of this requirement:
> > 
> > It is possible that the host that made a reservation dies 
> > "silently" without
> > releasing network resources allocated for its flow. This 
> > requirement will
> > provide protection from the possible waste of resources in 
> > this case. It is
> > definitely different from refreshing the soft state of the 
> > reservation since
> > it is driven by the application not the network specifics and 
> > applicable to
> > the hard reservations as well (and maybe even more 
> important for hard
> > reservations).  
> > To make this arrangement more flexible I think that ability 
> to signal
> > life-time of a reservation (including permanent reservations) 
> > should be
> > complemented by the ability to re-new the existing reservation.
> > I envision the following scenario:
> > The video endpoint (to stay on the same theme) is making a call. The
> > endpoint or may be proxy makes reservation request with 30 
> > min expected
> > life-time. Three options exist
> > 1. After 20 min the call is over and the endpoint (proxy) 
> > releases allocated
> > resources.
> > 2. After 25 min the participants realize that they need 
> > another 15 min to
> > finish discussion - the re-new reservation request is issued 
> > with 15 min
> > life-time
> > 3. After 15 min the endpoints crashes. 15 min later the 
> > network realize that
> > something is wrong and frees resources that were reserved for 
> > this video
> > call.
> > 
> > Does it make any sense?
> > 
> > Ilya
> > 
> > From: "Georgios Karagiannis (ELN)" 
> > <[e-mail]>
> > To: "'Schneider, Marco'" <[e-mail]>,
> > "'Steven Berson'"
> > <[e-mail]>
> > Cc: "'[e-mail]'" <[e-mail]>, [e-mail]
> > Subject: RE: [NSIS] Requirement Section 5.3.2
> > Date: Wed, 13 Mar 2002 13:43:32 +0100
> > charset="iso-8859-1"
> > 
> > Hi Marco
> > 
> > What I mean is the following.
> > If some QoS domain will use aggregated reservation states
> > and if the lifetime requirement has to be supported by the domain,
> > then new per flow reservation lifetime states have to be created
> > in this domain.
> > 
> > Best Regards,
> > Georgios
> > 
> > 
> > -----Original Message-----
> > From: Schneider, Marco [mailto:[e-mail]]
> > Sent: dinsdag 12 maart 2002 22:13
> > To: 'Georgios Karagiannis (ELN)'; 'Steven Berson'
> > Cc: '[e-mail]'; [e-mail]
> > Subject: RE: [NSIS] Requirement Section 5.3.2
> > 
> > 
> > Hi Georgios,
> > 
> > The point of the example is that the network may want to 
> > limit the duration
> > that it grants for a session and thus its corresponding 
> > resources (such as a
> > QOS connection). So in this case the network needs to be able 
> > to revoke
> > resources upon the expiration of some time period. In 
> > thinking about this
> > example I was wondering whether it would be useful to make 
> duration an
> > explicit part of the reservation semantics.
> > 
> > 1) A host requests from network a service of one hour 
> > duration. For example
> > a video call to a friend.
> > 2) Above is realized via session negotiation that results in 
> > token that is
> > passed back to the host. The token permits a QOS connection 
> > of one hour
> > duration at 5 Mbps
> > 3) The host (QOS Initiator) includes the token in the NSIS 
> > setup message
> > requesting a 5Mbps connection.
> > 4) The QOS Controller uses the token to validate the 
> > reservation and allows
> > the setup to go through.
> > (See draft-ietf-sip-call-auth-0?.txt as well as
> > draft-ietf-rap-session-auth-0?.txt)
> > 
> > Now what happens when one hour is up? Ideally the host releases the
> > resources but if the host does not the network will 
> > (otherwise the user gets
> > more than they paid for). When the network releases the 
> > resources there
> > should be a cause code that says your time was up or at the 
> very least
> > indicates that this was due to service policy.
> > 
> > Now my question is: given that the reservation is intended 
> to be of a
> > precise duration should we make this explicit or is it better 
> > for this to be
> > transparent? Is so why?
> > 
> > Regarding Scalability, I do not understand your claim that 
> > this is very
> > non-scalable. For every flow reservation the network 
> > presumably will need to
> > store the amount reserved (at least one piece of 
> > information). A reservation
> > duration requires one additional piece of information (at the 
> > edge) that
> > does not propagate across the network.
> > 
> > Best Regards,
> > Marco
> > 
> > _______________________________________________
> > nsis mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/nsis
> > 
> 

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