RE: [NSIS] Requirement Section 5.3.2

["Schneider, Marco" <[e-mail]>]

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

> -----Original Message-----
> From: Georgios Karagiannis (ELN)
> [mailto:[e-mail]]
> Sent: Tuesday, March 12, 2002 3:54 AM
> To: Schneider, Marco; 'Steven Berson'
> Cc: '[e-mail]'; [e-mail]
> Subject: RE: [NSIS] Requirement Section 5.3.2
> 
> 
> Hi Marco
> 
> I do not know if I understand your point.
> You can achieve the same operation by just explicitly 
> releasing the resources after one hour!
> Only the end host has to know that the resources 
> will be kept for one hour.
> 
> In this case the network will not have to store for each flow 
> the reservation time. If the network would do that 
> then we will have a very non-scalable solution, i.e.,
> increasing number of users the number of reservation
> lifetime states are increased.
> 
> However, I think Steve Berson had a reasonable solution on this:
> Emphasise in the requirement that advance reservations are not 
> required, but if you wanted advance reservations, then 
> reservation duration seems like a useful thing to have.
> 
> Best regards,
> Georgios
> 
> 
> 
> -----Original Message-----
> From: Schneider, Marco [mailto:[e-mail]]
> Sent: maandag 11 maart 2002 19:30
> To: 'Georgios Karagiannis (ELN)'; 'Steven Berson'
> Cc: '[e-mail]'; [e-mail]
> Subject: RE: [NSIS] Requirement Section 5.3.2
> 
> 
> Hi Georgios,
> 
> I think the ability to control reservation life-times may be a useful
> capability. Say for instance that I purchase a video call for one hour
> duration. NSIS should support the ability of the network to end the
> associated reservation after one hour. While this does not absolutely
> necessitate making the reservation lifetime an explicit part of the
> reservation request semantics, I think it would make sense to do so in
> support of this situation. 
> 
> Marco
> 
> 
> 
> 
> > -----Original Message-----
> > From: Georgios Karagiannis (ELN)
> > [mailto:[e-mail]]
> > Sent: Friday, March 08, 2002 1:36 PM
> > To: 'Steven Berson'
> > Cc: '[e-mail]'; [e-mail]
> > Subject: RE: [NSIS] Requirement Section 5.3.2
> > 
> > 
> > Hi Steve
> > 
> > The associated motivation given for this requirement 
> > in the NSIS WG draft is that "allows reducing the reservation 
> > update frequency in case of soft state based signaling." 
> (from draft)
> > 
> > Therefore, I thought that it was related to the soft-state refresh
> > timer. Do you have another motivation to keep this requirement.
> > 
> > Best regards,
> > Georgios
> > 
> > 
> > -----Original Message-----
> > From: Steven Berson [mailto:[e-mail]]
> > Sent: vrijdag 8 maart 2002 20:30
> > To: Georgios Karagiannis (ELN)
> > Cc: '[e-mail]'; [e-mail]
> > Subject: Re: [NSIS] Requirement Section 5.3.2
> > 
> > 
> > Georgios,
> > 
> > I am not sure if it is a good idea to support reservation 
> life-times, 
> > but at this time, it does not seem like a good idea to 
> preclude it.  
> > Also, the reservation life-time is not necessarily related to the 
> > soft-state refresh timer.
> > 
> > Steve
> > 
> > On Fri, 8 Mar 2002, Georgios Karagiannis (ELN) wrote:
> > 
> > > Hi Marcus
> > > 
> > > Regarding requirement in Section 5.3.2:
> > > 
> > > "Ability to signal life-time of a reservation":
> > > 
> > > The problem that I have with this requirement is that it will 
> > > increase the complexity of the functionality related to the soft 
> > > state (refresh) principle in a node.
> > > Please note that the soft state refresh principle is used
> > > to somehow solve unexpected changes in the network, e.g., 
> > route changes
> > > that are independent of the lifetime of a reservation.
> > > Therefore, I do not think that the lifetime of the reservation 
> > > should affect the duration of the soft state refresh.
> > > Please remove it!
> > > 
> > > Best regards,
> > > Georgios
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > 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