RE: [NSIS] Requirement Section 5.3.2

["Freytsis, Ilya" <[e-mail]>]

Hi Marco,

I like the way you stated this requirement.

Ilya

-----Original Message-----
From: Schneider, Marco [mailto:[e-mail]]
Sent: Friday, March 22, 2002 2:39 PM
To: 'Freytsis, Ilya'; '[e-mail]';
'[e-mail]'
Subject: RE: [NSIS] Requirement Section 5.3.2

Hi Ilya,

You have provided some interesting scenarios. This really points out the
danger of having a solution in mind while deciding requirements. In a soft
state solution the death of the host would be less important since the
reservation would time out.

I think the requirement for this first part is that the protocol must
support the ability to release resources in the case of initiator failure.
Not that in some cases such as a proxy controller in the network that
signals on behalf of many hosts, we must be able to support the behaviour
that the resources are not released.

With respect to the ability to signal reservation lifetime, I would propose
that we could make this part of service specific semantics. Thus the
designer of a service type could include a parameter to indicate the
lifetime. If a controller released a reservation due to the end of lifetime
the cause could be expressed in the service specific semantics and opaque to
the signaling protocol.

Marco

> -----Original Message-----
> From: Freytsis, Ilya [mailto:[e-mail]]
> Sent: Thursday, March 14, 2002 9:57 PM
> To: '[e-mail]'; '[e-mail]';
> Schneider,
> Marco
> 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