Subject: RE: [NSIS] Requirement Section 5.3.2

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Fri, 8 Mar 2002 20:50:06 +0100

Hi Steve

Okay, but this should be then made very clear.
In my opinion it is not clear!

Best Regards,
Georgios

-----Original Message-----
From: Steven Berson [mailto:[email-masked]]
Sent: vrijdag 8 maart 2002 20:45
To: Georgios Karagiannis (ELN)
Cc: [email-masked]'; [email-masked]
Subject: RE: [NSIS] Requirement Section 5.3.2

Georgios,

Section 5.3.2 mentions that advance reservations are not required, but 
if you wanted advance reservations, then reservation duration seems 
like a useful thing to have.

Steve

On Fri, 8 Mar 2002, Georgios Karagiannis (ELN) wrote:

> 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:[email-masked]]
> Sent: vrijdag 8 maart 2002 20:30
> To: Georgios Karagiannis (ELN)
> Cc: [email-masked]'; [email-masked]
> 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
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/nsis
> > 
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 

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

---

From: "Schneider, Marco" <[email-masked]>
Date: Mon, 11 Mar 2002 12:29:52 -0600

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

> From: Georgios Karagiannis (ELN)
> [mailto:[email-masked]]
> Sent: Friday, March 08, 2002 1:36 PM
> To: 'Steven Berson'

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Tue, 12 Mar 2002 10:54:02 +0100

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:[email-masked]]
Sent: maandag 11 maart 2002 19:30
To: 'Georgios Karagiannis (ELN)'; 'Steven Berson'
Cc: [email-masked]'; [email-masked]
Subject: RE: [NSIS] Requirement Section 5.3.2

Hi Georgios,

Marco

---

From: "Schneider, Marco" <[email-masked]>
Date: Tue, 12 Mar 2002 15:12:50 -0600

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

> Sent: Tuesday, March 12, 2002 3:54 AM
> To: Schneider, Marco; 'Steven Berson'

---

From: "Schneider, Marco" <[email-masked]>
Date: Tue, 12 Mar 2002 15:22:44 -0600

Juan Carlos,

Please see my reply to Georgios. I agree with what you wrote below, so
perhaps my post was not interpreted as intended. (see one comment below as
well).

Marco

> From: [email-masked] 
> [mailto:[email-masked]]
> Sent: Tuesday, March 12, 2002 7:03 AM
> Cc: Schneider, Marco; 'Steven Berson'; [email-masked]';
> [email-masked]
> Hi all,
> I agree with Georgis reasoning.
> If the NSIS protocol is focusing on bearers only, then it 
> should have no
> knowledge on services like, e.g. "video calls", but only on 
> bearers having
> some properties (bandwidth, delay, etc.), no matter what 
> those bearers are
> carrying, no matter for which services they are being used.
> If you "purchase a video call for one hour duration", then 
> the duration of
> the *service* is one hour, and that's what you are paying for.
The issue is what are the mechanisms to enforce that the corresponding
resources last for one hour and how do the host, session controllers, and
qos controllers participate in this.

> Best regards
> 
>      Juan Carlos
> 
> 
> 
> 
> 
> "Georgios Karagiannis (ELN)" <[email-masked]>
> @ietf.org on 12/03/2002 10:54:02
> 
> Sent by:  [email-masked]
> 
> 
> To:   "'Schneider, Marco'" <[email-masked]>, "'Steven Berson'"
>       <[email-masked]>
> cc:   "[email-masked]'" <[email-masked]>, [email-masked]

---

From: "Freytsis, Ilya" <[email-masked]>
Date: Thu, 14 Mar 2002 22:57:14 -0500

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)" <[email-masked]>
To: "'Schneider, Marco'" <[email-masked]>,
"'Steven Berson'"
<[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, [email-masked]
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:[email-masked]]
Sent: dinsdag 12 maart 2002 22:13
To: 'Georgios Karagiannis (ELN)'; 'Steven Berson'
Cc: [email-masked]'; [email-masked]
Subject: RE: [NSIS] Requirement Section 5.3.2

Hi Georgios,

Best Regards,
Marco

---

From: [email-masked]
Date: Fri, 15 Mar 2002 09:07:18 +0100

Hi Ilya,

That's sounds much better:
It's up to the service to decide on durations, and when and how to release
resources, mainly because these resources are there to provide a service.
This does not preclude in anyway to foresee a "time to live" mechanism
(with periodic refreshes, or one single duration indicated at the
beginning, etc.), but only for *protection* reasons, and nothing else.
Now, if the IP level is able to autonomously release resources, it must
report that to the end-point (QoS initiator ?).

Best regards,
Juan Carlos

"Freytsis, Ilya" <[email-masked]>@ietf.org on 15/03/2002 04:57:14

To:   "[email-masked]'" <[email-masked]>,
      "[email-masked]'"
      <[email-masked]>, "[email-masked]'"
       <[email-masked]>
cc:
Subject:  RE: [NSIS] Requirement Section 5.3.2

Hi Georgios,

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

Hi Marco

Best Regards,
Georgios

-----Original Message-----
From: Schneider, Marco [mailto:[email-masked]]
Sent: dinsdag 12 maart 2002 22:13
To: 'Georgios Karagiannis (ELN)'; 'Steven Berson'
Cc: [email-masked]'; [email-masked]
Subject: RE: [NSIS] Requirement Section 5.3.2

Hi Georgios,

that it grants for a session and thus its corresponding resources (such as
a

resources but if the host does not the network will (otherwise the user
gets

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

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Fri, 15 Mar 2002 09:18:21 +0100

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:[email-masked]]
Sent: vrijdag 15 maart 2002 4:57
To: [email-masked]'; [email-masked]';
[email-masked]'

Hi Georgios,

Does it make any sense?

Ilya

Hi Marco

Best Regards,
Georgios

-----Original Message-----
From: Schneider, Marco [mailto:[email-masked]]
Sent: dinsdag 12 maart 2002 22:13
To: 'Georgios Karagiannis (ELN)'; 'Steven Berson'
Cc: [email-masked]'; [email-masked]
Subject: RE: [NSIS] Requirement Section 5.3.2

Hi Georgios,

Best Regards,
Marco

---

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 15 Mar 2002 09:30:43 -0000

Georgios,

Please, let's not mix together the requirements and the solution at this stage! Soft state might be a (or even the) solution, but that doesn't make it a requirement!

In fact, we have at least three independent state-related requirements to consider:
1) the fact that the application wants a bearer of a limited duration (and only wants to pay for this duration) - the end user might want quite precise timing control over this (for accounting reasons)
2) the need to clean up after a node dies or becomes disconnected from the network (in which case explicit release isn't possible)
3) the need to re-install state after path (route) changes (which might be managed by something routing-aware)

Soft-state *can* solve all these, but in some scenarios it might be *very* hard to find a good compromise soft-state timer value considering all the effects. Also, in some scenarios (e.g. mobile) it might be better to address some of the problems (e.g. 3) in a different, specialised way. But in that case, it's helpful to have explicitly the requirement that there are other reasons for needing refresh or timeout or explicit release or whatever.

Personally, I like Ilya's description of the situation. But we could make things less judgemental by saying "it must be possible for an initiator to control reservation reservation end times without requiring continuous signalling with the network" (or something); we can think later whether relying always on soft state or allowing explicit lifetimes is a better solution. I certainly don't see why explicit lifetimes are so hard.

Robert H.

> Sent: 15 March 2002 08:18
> To: 'Freytsis, Ilya'; [email-masked]'; [email-masked]'

---

From: [email-masked]
Date: Sat, 16 Mar 2002 01:10:21 +0200

Hi All,

Looking at this requirement from another direction, it seems
that the requirement is really about supporting time-based
reservations.  Is this the real requirement?  If so,
do we support this?

John

> From: ext Hancock, Robert [mailto:[email-masked]]
> Sent: 15 March, 2002 11:31
> To: 'Georgios Karagiannis (ELN)'; 'Freytsis, Ilya'; [email-masked]';
> [email-masked]'
> Please, let's not mix together the requirements and the 
> solution at this stage! Soft state might be a (or even the) 
> solution, but that doesn't make it a requirement!
> 
> 1) the fact that the application wants a bearer of a limited 
> duration (and only wants to pay for this duration) - the end 
> user might want quite precise timing control over this (for 
> accounting reasons)
> 2) the need to clean up after a node dies or becomes 
> disconnected from the network (in which case explicit release 
> isn't possible)
> 3) the need to re-install state after path (route) changes 
> (which might be managed by something routing-aware)
> 
> Soft-state *can* solve all these, but in some scenarios it 
> might be *very* hard to find a good compromise soft-state 
> timer value considering all the effects. Also, in some 
> scenarios (e.g. mobile) it might be better to address some of 
> the problems (e.g. 3) in a different, specialised way. But in 
> that case, it's helpful to have explicitly the requirement 
> that there are other reasons for needing refresh or timeout 
> or explicit release or whatever.
> 
> Personally, I like Ilya's description of the situation. But 
> we could make things less judgemental by saying "it must be 
> possible for an initiator to control reservation reservation 
> end times without requiring continuous signalling with the 
> network" (or something); we can think later whether relying 
> always on soft state or allowing explicit lifetimes is a 
> better solution. I certainly don't see why explicit lifetimes 
> are so hard.
> 
> Robert H.
>

---

From: [email-masked]
Date: Sat, 16 Mar 2002 01:07:37 +0200

Hi all,

> the *service* is one hour, and that's what you are paying for.

I agree - for example TCP connections are not time based ....

John

---

From: "Schneider, Marco" <[email-masked]>
Date: Fri, 22 Mar 2002 13:38:41 -0600

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

> From: Freytsis, Ilya [mailto:[email-masked]]
> Sent: Thursday, March 14, 2002 9:57 PM
> Schneider,

---

From: "Freytsis, Ilya" <[email-masked]>
Date: Fri, 22 Mar 2002 18:57:44 -0500

Hi Marco,

I like the way you stated this requirement.

Ilya

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

Hi Ilya,

Marco