Subject: RE: pre-emption (was RE: [NSIS] proposals related to NSIS WGdraf t)

From: [email-masked]
Date: Mon, 8 Apr 2002 11:20:28 +0300

Hi Marcus,

> We are not talking about priority of data traffic overothers, 
> but on the case of the capacity already completly give away and a new 
> service request arriving. One can then specify, whether it is possible to preempt 
> guaranteed reservations.
> 
> I would like see whether this is worth a reqirement.

I don't support this requirement.

John

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

---

From: [email-masked]
Date: Mon, 8 Apr 2002 10:30:04 +0200

John, 

How do you plan to deal with 112(911)-calls in this case? There are sometimes regulation (if I remember correctly) that require a network to support that a 112-call always gets delivered.

My concern regarding preemption is this single instance - if this is solved it is fine by me. Ie I do not see the need for a generic pre-emption mechanism. I think a combination of randomness and planning (for mobile handoffs) gives suitable behaviour. 

Anders

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: den 8 april 2002 10:20
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: pre-emption (was RE: [NSIS] proposals related to NSIS
> WGdraf t)
> 
> 
> Hi Marcus,
>

---

From: [email-masked]
Date: Mon, 8 Apr 2002 11:34:49 +0300

Hi Anders,

> How do you plan to deal with 112(911)-calls in this case? 
> There are sometimes regulation (if I remember correctly) that 
> require a network to support that a 112-call always gets delivered.

I don't see emergency calls listed anywhere in our charter.
This is outside of the scope, in my opinion.

There is a working group focusing on this issue:
http://www.ietf.org/html.charters/ieprep-charter.html

In Minneapolis, I chatted with one of ADs about the applicability
of NSIS for Internet Emergency Preparedness work, and he felt
that NSIS was very applicable.  My feeling is that he (as AD) will
not let us go down the wrong road, however.

Again, however, NSIS is not chartered to work on services, and
at the end of the day, emergency calls are a service.

John

---

From: [email-masked]
Date: Mon, 8 Apr 2002 10:49:36 +0200

John, 

not sure I understand, requesting resources for something is in charter, I persume. What I stated was: there is one instance where I see a need for pre-emption in signaling and this is related to emergency calls. 

The impact of this statement is that pre-emption have to be taken into account by NSIS - unless you find another way of solving the problem of making resources available for an "emergency call". I am definitely talking about a resource allocation / signaling problem and not the "emergency call" service. Thus in scope in my opinion. 

If somebody can invalidate this statement (ie implement this feature by not including information in the signaling message) then I suggest remove this requirement. If you can't then the requirement to support pre-emption has to be in the NSIS req. draft. 

Anders

> Sent: den 8 april 2002 10:35
> To: Bergsten, Anders P. /Research /0920-754 50, 070-661 44 98
> Cc: [email-masked]

---

From: [email-masked]
Date: Mon, 8 Apr 2002 11:52:54 +0300

Hi Anders,

> not sure I understand, requesting resources for something is 
> in charter, I persume. What I stated was: there is one 
> instance where I see a need for pre-emption in signaling and 
> this is related to emergency calls. 

Should the protocol support pre-emption or should the network?

My opinion is that it is network policy to determine how to
do pre-emption, not a protocol issue.

John

---

From: "Schneider, Marco" <[email-masked]>
Date: Wed, 10 Apr 2002 22:17:47 -0500

Related to the issue of preemption, a group of us discussed the issue of
reservation lifetime while in Minneapolis. Our conclusion was that this
could be done transparently by building it into the service description
which is carried by, but not visible to, NSIS. Reservation lifetime would
only be seen in a service specific field which is part of the service
description and transparent to NSIS. 

It seems to me that while pre-emption is a different concern than
reservation lifetime, it still can be supported in the same way. The only
requirement that seems necessary is that NSIS must support the ability of a
QOS controller to release an existing connection. Specific cause codes would
be specific to the service and are out of scope and transparent to NSIS.

Comments?

Marco

> Sent: Monday, April 08, 2002 3:53 AM
> To: [email-masked]
> Cc: [email-masked]

---

From: [email-masked]
Date: Thu, 11 Apr 2002 11:34:16 +0300

Hi Marcus,

> I agree with you that it is a network issue, and that on a 
> user to network interface pre-emption might not make sense. But 
> does this hold as well for network oriented scenarios? E.g., we 
> plane to add a scenario where Voice  gateways signal for QoS 
> (in an intra-domain case -> same administrative 
> domain).
> 
> Does this also mean that pre-emption is not a signaling 
> protocol issue? Or did we forgot about it?

Do you see a case for it?  I think that it is a network /
service issue actually.   For a provider who is providing
mostly secure data transport & selling extra capacity
for voice, the provider may wish to protect the data
traffic (imagine some sort of financial services data)
and the voice is secondary ....

In my opinion, the service should be able to mark traffic
and set policy.  I'm not sure if this is a direct signaling
protocol issue, but more about how the services is provisioned
/ provided.

John

---

From: "Freytsis, Ilya" <[email-masked]>
Date: Thu, 11 Apr 2002 09:54:46 -0400

Marco,

I fully support your position. Honestly, I was a little bit surprised by the
intensity of this discussion and how much time it has taken. I still do not
understand what exactly James (Polk) wanted to see included in NSIS
requirements.

Ilya

Comments?

Marco

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Thu, 11 Apr 2002 16:26:47 -0500

Hi,

I have not been following this discussion closely, so sorry if this
has been brought up. My question is, if NSIS does not intend
to use refreshes and just add reservation lifetime as opaque info
to the NSIS messages, then inherent reliability mechanism that
RSVP was getting from refreshes is gone??

Did I miss something?

Regards,
Madjid

-----Original Message-----
From: Freytsis, Ilya [mailto:[email-masked]]
Sent: Thursday, April 11, 2002 8:55 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: pre-emption (was RE: [NSIS] proposals related to NSIS WGdraf t) 

Marco,

Ilya

Comments?

Marco

---

From: "Freytsis, Ilya" <[email-masked]>
Date: Fri, 12 Apr 2002 00:14:26 -0400

Madjid,

Reservation lifetime (applicable for soft reservations as well as hard
reservations) is not meant to replace the refreshes that are needed for the
soft state based reservations. 

Ilya

-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
Sent: Thursday, April 11, 2002 5:27 PM
To: 'Freytsis, Ilya'; [email-masked]
Cc: [email-masked]
Subject: RE: pre-emption (was RE: [NSIS] proposals related to NSIS WGdraf t)

Hi,

Did I miss something?

Regards,
Madjid

-----Original Message-----
From: Freytsis, Ilya [mailto:[email-masked]]
Sent: Thursday, April 11, 2002 8:55 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: pre-emption (was RE: [NSIS] proposals related to NSIS WGdraf t)

Marco,

Ilya

Comments?

Marco

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Fri, 12 Apr 2002 15:43:58 +0200

Hi Marco

I agree with your proposal!

Best regards,
georgios

-----Original Message-----
From: Schneider, Marco [mailto:[email-masked]]
Sent: donderdag 11 april 2002 5:18
To: [email-masked]'; [email-masked]
Cc: [email-masked]
Subject: RE: pre-emption (was RE: [NSIS] proposals related to NSIS
WGdraf t)

Comments?

Marco