RE: [NSIS] Requirement Section 5.3.2
Juan-Carlos.Rojas@alcatel.fr Fri, 15 March 2002 08:26 UTC
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23421 for <nsis-archive@odin.ietf.org>; Fri, 15 Mar 2002 03:26:01 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA26872 for nsis-archive@odin.ietf.org; Fri, 15 Mar 2002 03:26:02 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA26073; Fri, 15 Mar 2002 03:07:57 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA26040 for <nsis@optimus.ietf.org>; Fri, 15 Mar 2002 03:07:54 -0500 (EST)
Received: from aifhs8.alcatel.fr (una200.alcatel.fr [212.208.74.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23228 for <nsis@ietf.org>; Fri, 15 Mar 2002 03:07:51 -0500 (EST)
From: Juan-Carlos.Rojas@alcatel.fr
Received: from frmail25.netfr.alcatel.fr (frmail25.netfr.alcatel.fr [155.132.182.155]) by aifhs8.alcatel.fr (ALCANET/SMTP2) with ESMTP id JAA15110; Fri, 15 Mar 2002 09:07:20 +0100 (MET)
Subject: RE: [NSIS] Requirement Section 5.3.2
To: "Freytsis, Ilya" <ifreytsis@cetacean.com>
Cc: "'nsis@ietf.org'" <nsis@ietf.org>, "'Georgios.Karagiannis@eln.ericsson.se'" <Georgios.Karagiannis@eln.ericsson.se>, "'schneider@tri.sbc.com'" <schneider@tri.sbc.com>
Date: Fri, 15 Mar 2002 09:07:18 +0100
Message-ID: <OF4F8DEE2F.40A1CDDC-ONC1256B7D.002BEC7D@netfr.alcatel.fr>
X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/15/2002 09:07:20
MIME-Version: 1.0
Content-type: text/plain; charset="us-ascii"
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Next Steps in Signaling <nsis.ietf.org>
X-BeenThere: nsis@ietf.org
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" <ifreytsis@Cetacean.com>@ietf.org on 15/03/2002 04:57:14 Sent by: nsis-admin@ietf.org To: "'nsis@ietf.org'" <nsis@ietf.org>, "'Georgios.Karagiannis@eln.ericsson.se'" <Georgios.Karagiannis@eln.ericsson.se>, "'schneider@tri.sbc.com'" <schneider@tri.sbc.com> cc: 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 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis
- [NSIS] NSIS Scope Discussion Tricci So
- Re: [NSIS] Requirement Section 5.3.2 Steven Berson
- RE: [NSIS] Requirement Section 5.3.2 Georgios Karagiannis (ELN)
- RE: [NSIS] Requirement Section 5.3.2 Georgios Karagiannis (ELN)
- RE: [NSIS] Requirement Section 5.3.2 Steven Berson
- RE: [NSIS] Requirement Section 5.3.2 Schneider, Marco
- RE: [NSIS] Requirement Section 5.3.2 Georgios Karagiannis (ELN)
- RE: [NSIS] Requirement Section 5.3.2 Juan-Carlos.Rojas
- RE: [NSIS] Requirement Section 5.3.2 Schneider, Marco
- RE: [NSIS] Requirement Section 5.3.2 Schneider, Marco
- RE: [NSIS] Requirement Section 5.3.2 Georgios Karagiannis (ELN)
- RE: [NSIS] Requirement Section 5.3.2 Steven Berson
- RE: [NSIS] Requirement Section 5.3.2 Georgios Karagiannis (ELN)
- Re: [NSIS] Requirement Section 5.3.2 Nguyen Thi Mai Trang
- RE: [NSIS] Requirement Section 5.3.2 Freytsis, Ilya
- RE: [NSIS] Requirement Section 5.3.2 Juan-Carlos.Rojas
- RE: [NSIS] Requirement Section 5.3.2 Georgios Karagiannis (ELN)
- RE: [NSIS] Requirement Section 5.3.2 Hancock, Robert
- RE: [NSIS] Requirement Section 5.3.2 john.loughney
- RE: [NSIS] Requirement Section 5.3.2 john.loughney
- RE: [NSIS] Requirement Section 5.3.2 Schneider, Marco
- RE: [NSIS] Requirement Section 5.3.2 Freytsis, Ilya