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:ifreytsis@Cetacean.com]
Sent: vrijdag 15 maart 2002 4:57
To: 'nsis@ietf.org'; 'Georgios.Karagiannis@eln.ericsson.se';
'schneider@tri.sbc.com'
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)" <Georgios.Karagiannis@eln.ericsson.se>
To: "'Schneider, Marco'" <schneider@tri.sbc.com>,
"'Steven Berson'"
<berson@isi.edu>
Cc: "'brunner@ccrle.nec.de'" <brunner@ccrle.nec.de>, nsis@ietf.org
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:schneider@tri.sbc.com]
Sent: dinsdag 12 maart 2002 22:13
To: 'Georgios Karagiannis (ELN)'; 'Steven Berson'
Cc: 'brunner@ccrle.nec.de'; nsis@ietf.org
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
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis