Re: [NSIS] Requirement Section 5.3.2

[Nguyen Thi Mai Trang <[e-mail]>]

Hi Georgos et al,
IMHO, if the domain uses Policy-based networking concept where the
centralized QoS control point (maybe the QC if I well understand)
corresponds to the PDP, edge routers correspond to PEPs, the lifetime
information may be maintained by the PDP, not on all edges. At the
start-time and the end-time of the lifetime, the PDP will push
neccessary information only to some edges concerning.
Best regards,
Mai Trang

Georgios Karagiannis (ELN) wrote:
> 
> 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

-- 
---------------------------------------
NGUYEN Thi Mai Trang
Ecole Nationale Superieure des Telecommunications
Departement INFRES - Bureau C 234-4
46, rue Barrault - 75013 Paris
Tel: (+33) (-0)1 45 81 74 61 - Fax : (+33) (-0)1 45 81 31 19
email : [e-mail]
---------------------------------------

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