RE: [NSIS] Requirement Section 5.3.2

["Georgios Karagiannis (ELN)" <[e-mail]>]

Hi Steve

But it will be still required to be stored on all edges.
Some edges only need to maintain aggregated states.


Best Regards,
Georgios


-----Original Message-----
From: Steven Berson [mailto:[e-mail]]
Sent: woensdag 13 maart 2002 19:15
To: Georgios Karagiannis (ELN)
Cc: 'Schneider, Marco'; '[e-mail]'; [e-mail]
Subject: RE: [NSIS] Requirement Section 5.3.2


Georgios,

My understanding of what Marco wrote is that the lifetime information
is stored only at the edge.  The core would not need to store the
lifetime information, and so aggregation (without lifetimes) can still
be done in the core.

Steve

On Wed, 13 Mar 2002, Georgios Karagiannis (ELN) wrote:

> 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
> 
> > -----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
> 

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