Subject: [NSIS] attempted summary of pre-emption thread

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 9 Apr 2002 15:06:17 +0100

dear all,

well, this is quite a thread to come back from a short holiday to.
I attempt to make a summary (partly for my own benefit):

==================
1. pre-emption (let's call it 'session pre-emption'?) is a useful and sometimes mandatory capability within networks (examples: emergency call handling; operation after capacity loss e.g. due to partial network failure).

2. only the network can decide what sessions to pre-empt in favour of what other sessions.

3. QoS signalling has to carry enough information to enable the network to make this decision (and that information might have to be authenticated or otherwise processed to classify the session securely); however, this information does not need to be visible to the signalling protocol.

4. if a session is pre-empted, the network might (should?) want to tell affected users that their QoS has been degraded.
==================

If this is complete, the implications for NSIS would seem to be:
A) from (3), the QoS data carried has to include particular information - but since this is opaque to us anyway, there is no new requirement here.
B) in support of (4), the signalling protocol has to be able to send an asynchronous message about a QoS change - but I think we also have this already (for other reasons).

So, no new requirements. But maybe some more pointers about how important (B) is and where in the network. (But note: (B) isn't needed to support pre-emption, it's just a side effect of doing pre-emption, so maybe the added significance is not great.)

I've thought hard in the past but can't think of any new requirements for NSIS from this topic. I'd be interested to see any.
If this method of reasoning is useful, maybe it is helpful to capture it in the requirements appendix as a scenario ("here's how a pre-emption event is handled and what NSIS capabilities are used to do so"), or is that a framework issue?

robert h.
now to the handover one ...

---

From: "Gary Kenward"<[email-masked]>
Date: Tue, 9 Apr 2002 13:07:29 -0400

Robert:

  As a follow up: it is my understanding that IEPREP (and GETS) 
is targeting non-pre-emptive support for emergency traffic. 
Perhaps someone on this list active the IEPREP can expand upon (or correct)
this requirement. I did a quick scan of the IEPREP wg drafts, and although
there are discussions of QoS requirements, only one discussion pre-emption
and then, only as an option. 

  Regardless, the Diff Serv working group is considering extensions
to the current definitions of the code space (I cannot comment, however,
on what the consensus is). If there is a need to add pre-emption as one
of the forwarding services provided to a traffic flow, then the proposal
should be made to the Diff Serv wg.

Regards,
Gary

> -----Original Message-----
> From: Hancock, Robert [mailto:[email-masked]]
> Sent: April 9, 2002 10:06
> To: [email-masked]
> Subject: [NSIS] attempted summary of pre-emption thread
> 
> 
> dear all,
> 
> 1. pre-emption (let's call it 'session pre-emption'?) is a 
> useful and sometimes mandatory capability within networks 
> (examples: emergency call handling; operation after capacity 
> loss e.g. due to partial network failure).
> 
> 3. QoS signalling has to carry enough information to enable 
> the network to make this decision (and that information might 
> have to be authenticated or otherwise processed to classify 
> the session securely); however, this information does not 
> need to be visible to the signalling protocol.
> 
> 4. if a session is pre-empted, the network might (should?) 
> want to tell affected users that their QoS has been degraded.
> ==================
> 
> A) from (3), the QoS data carried has to include particular 
> information - but since this is opaque to us anyway, there is 
> no new requirement here.
> B) in support of (4), the signalling protocol has to be able 
> to send an asynchronous message about a QoS change - but I 
> think we also have this already (for other reasons).
> 
> So, no new requirements. But maybe some more pointers about 
> how important (B) is and where in the network. (But note: (B) 
> isn't needed to support pre-emption, it's just a side effect 
> of doing pre-emption, so maybe the added significance is not great.)
> 
> I've thought hard in the past but can't think of any new 
> requirements for NSIS from this topic. I'd be interested to see any.
> If this method of reasoning is useful, maybe it is helpful to 
> capture it in the requirements appendix as a scenario 
> ("here's how a pre-emption event is handled and what NSIS 
> capabilities are used to do so"), or is that a framework issue?
> 
> robert h.

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 09 Apr 2002 14:09:13 -0500

At 03:06 PM 4/9/2002 +0100, Hancock, Robert wrote:

I'm confused by your conclusions. Let me quote you, but rearrange what you
wrote to show this below. 

You stated 2 times that QOS information was necessary in the signaling:
>
>3. QoS signalling has to carry enough information to enable the network to 
>make this decision (and that information might have to be authenticated or 
>otherwise processed to classify the session securely); 

>A) from (3), the QoS data carried has to include particular information - 

and that if preemption does occur, the "network" should tell someone:

>4. if a session is pre-empted, the network might (should?) want to tell 
>affected users that their QoS has been degraded.
>==================
>
yet state this information now *doesn't* need to be included here:

>however, this 
>information does not need to be visible to the signalling protocol.
>

and conclude with "no new requirement" for preemption:

>but since this is opaque to us anyway, there is no new requirement here.

>So, no new requirements. 
>
>I've thought hard in the past but can't think of any new requirements for 
>NSIS from this topic. I'd be interested to see any.

Your logic within your email is flawed and poorly written, and doesn't support
the conclusion you wrote. Please review what you wrote that I've highlighted
above near the top and tell me how you stated that this information "~ ...has
to include particular (identifying) information (for preemption to properly be
performed)....", yet conclude that it "~...isn't needed....So, no new
requirements."

>robert h.
Robert - you didn't read my email obviously as I stated many networks that have
this capability that NSIS *won't* be an appropriate QOS mechanism for
interfacing with if this is not included... 

*************************************
"People generally demand more respect for their own rights than they are
willing to allow for others"

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike 
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 09 Apr 2002 13:49:30 -0500

> and then, only as an option. 

I am involved within the IEPREP WG (spoke at the Minn meeting - and not about
preemption) and preemption has been a topic of many long threads there.
Preemption has been agreed upon to be optional in many networks, mandatory in
others, while not_practiced or not_allowed in still others. As a result,
preemption will be explicitly mentioned within that WG's Framework and
Requirements IDs in future releases (both are only -00 now). 

> > From: Hancock, Robert
> [<mailto:[email-masked]>mailto:[email-masked]] 

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems

---

From: "Gary Kenward"<[email-masked]>
Date: Tue, 9 Apr 2002 18:29:49 -0400

First of all, it's not "my working group".  Second, I can list at least a
dozen wg's which someone at 
the IETF has stated should should not exist or will never be productive.
Many have
completed their work and the results are being put to practice. Minority
opinions abound in the IETF.
 
Second, perhaps you might actually identify the so called "capability" that
you refer too instead of
throwing petty invectives around. So far, all anyone has heard is a
suggestion for a new type of QoS,
which is not in the charter. The IETF has at least two wg's looking at QoS,
and they do not need another.
If pre-emption is so important, why not propose it to the Diff Serv wg?
 
Gary Kenward

-----Original Message-----
From: James M. Polk [mailto:[email-masked]]
Sent: April 9, 2002 17:26
To: Kenward, Gary [WDLN2:AN10:EXCH]
Subject: RE: [NSIS] attempted summary of pre-emption thread

At 04:01 PM 4/9/2002 -0400, you wrote: 

  This is a very different approach from SS7, UNI, SSCPS, GSM, UMTS, .... IP
is an 
internetworking protocol, and must work across many different networks. NSIS
should 
also work across all (predominant) networks. Given the alternative of
defining variants 
of the protocol for every network, it is often more productive to define a
generic capability, 
and leave the network specific stuff to the respective SDOs. 

Regards, 
Gary 

I really have no skin in this game and don't really care if you bury your
head in the sand about this -- it'll just force whoever wants this
capability to *not* look to NSIS for a solution. I was suggesting that this
be an option, not even mandatory to implement, and you shut the suggestion
down.... What you are doing is siding with the idealist engineering aspect
of this question, and not including any pragmatic or business aspects.... 

I've heard directly from several people that I respect within the IETF at
IETF meetings they themselves don't have a lot of faith in your WG producing
anything of substance, if anything at all..... you're proving them right to
me now

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike 
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com <http://www.cisco.com/>

---

From: [email-masked]
Date: Wed, 10 Apr 2002 09:21:22 +0300

James,

> I am involved within the IEPREP WG (spoke at the Minn meeting - 
> and not about preemption) and preemption has been a topic of 
> many long threads there. Preemption has been agreed upon to be 
> optional in many networks, mandatory in others, while not_practiced 
> or not_allowed in still others. As a result, preemption will be 
> explicitly mentioned within that WG's Framework and Requirements 
> IDs in future releases (both are only -00 now). 

I understand the discussion in IEPREP.  The current system in the PSTN
uses the priority bits in the SS7 signaling messages to ensure a better
call completion rate, it doesn't attempt pre-emption.

In many GSM networks, an emergency call (911 or 112) will generally 
clear a radio channel, if all radio channels are full.

However, with regards to NSIS, I am not sure what you asking for.
I can see the following possibilities (not that I am saying NSIS should
do them):

	1) Set a bit in signaling message to indicate priority
	2) define a state machine on how to handle this bit
	3) define rules for handling this bit
	4) define default behaviors
	5) nothing

What is it that you see is needed?  Is this something that should
be handled in the requirements, in the framework or in the
protocol?  How do we handle differing requirements due to local
regulation?  Does IEPREP have a documented recommendation for this?

John

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

---

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 10 Apr 2002 12:55:01 +0100

Martin,

You capture the point quite well: the type of QoS information being signalled has implications for the message sequences that the protocol needs to support, and these are then requirements for NSIS. 

We already tried (in minneapolis) to capture the basic request/response case (anders has written something on this i think), the intended essence of points (4) and (B) of the summary was that pre-emption implies some support for asynchronous notification as well, for the reasons you state. (does the summary miss something here or is it just not clear enough?)

I think there is currently a working assumption in (some parts of) the group that defining QoS classes/parameters is not part of the work of NSIS, but deciding how to signal them is. But I don't think that this is really captured as a concrete point anywhere (it is discussed in the #53 minutes, but on the other hand contradicts the charter, so it's not totally surprising that there might be some confusion).

I'm currently trying to write something that states this division and the implications more precisely. Actually, it relates to more than just message sequences (although that is the main point).

Robert H.

> From: Martin Karsten [mailto:[email-masked]]
> Sent: 10 April 2002 12:04
> To: Gary Kenward
> Cc: [email-masked]; Hancock, Robert; [email-masked]
> Subject: Re: [NSIS] attempted summary of pre-emption thread
> 
> 
> It might be obivous not to do, but someone could have the 
> idea to design
> e.g. the following signalling protocol:
> 
> 1) initiator sends QoS request and waits for confirmation (or reject)
> 2a) a network entity rejects the request and sends reject 
> towards initiatior
> 2b) all network entities accept the request, so it arrives at 
> remote end
> 3) remote end sends confirmation
> 4) transmission time (maybe including periodic state refresh)
> 5) initiator sends teardown (maybe through state timeout)
> 6) (optional) remote end sends tear confirmation
> 
> Then the initiator would never be prepared to handle an 
> asynchronous tear
> notification. If preemption capability shall be supported 
> properly, however,
> the initiator must be prepared to receive such a notification.
> 
> This is the most simple example that comes to my mind, of how 
> preemption
> capability might influence the communication pattern. There 
> might be other
> and more complex examples, depending on the rest of the 
> requirements. Maybe
> James can jump in clarify whether this captures his view.
> 
> Martin
> 
> >  Could you expand upon your point for me. I do not understand
> > the tight relationship being assigned between (bearer traffic?)
> > pre-emption, and signalling semantics.
> > 
> > Gary
> > 
> > > From: Martin Karsten [mailto:[email-masked]]
> > > Sent: April 9, 2002 19:18
> > > Cc: 'James M. Polk'; Hancock, Robert; [email-masked]
> > > Subject: Re: [NSIS] attempted summary of pre-emption thread
> > > 
> > > 
> > > >   Robert's email was clear to me, and well stated. He 
> was saying that
> > > > if there is a requirement for pre-emption, then it can 
> be captured in
> > > > the data description (hopefully, an opaque TLV data 
> chunk) for the
> > > > QoS, and there is no need for a change in the 
> requirements for NSIS.
> > > 
> > > I have to admit that I did not follow the complete 
> thread, but maybe it
> > > helps to distinguish "preemption" from "priority".
> > > 
> > > The "priority" of a request can be encoded in the QoS 
> specification, but
> > > "preemption" capability (beyond packet preemption aka "drop" ;-),
> > > including informing all participating entities, mandates a certain
> > > asynchronous communication pattern, which must be taken 
> into account
> > > when designing the signalling protocol and thus, seems to 
> belong to the
> > > requirements.
> > > 
> > > Martin
> > >

---

From: "Gary Kenward"<[email-masked]>
Date: Wed, 10 Apr 2002 10:24:40 -0400

Martin:

  If I understand this example correctly, the issue is the relationship
between the state of the initiator and the arrival of asynchronous messages
that should change that state?

Gary

> Sent: April 10, 2002 07:04
> Cc: [email-masked]; [email-masked]; [email-masked]

---

From: "Gary Kenward"<[email-masked]>
Date: Wed, 10 Apr 2002 15:15:14 -0400

Behcet:
   
   Can or should, the IETF does not specify state machine
behaviours. Certainly not to the level that details such as
pre-emption of that state machine can be identified. Regardless,
I may have focussed on the wrong model to make my point.
 
   There have been two debates raging here. To attempt to close 
the second debate, the one concerning asynchronous
pre-emption of the signalling itself, how about we agree that 
some messages will pre-empt ongoing operations, but that this 
outcome is an implicit result of the semantics of the message sequences, 
not dependent upon the existence of a pre-emption bit or field in a message
(note: I may be tying two different proposals together here,
but somehow one morphed into another, and I'm not clear where
one ends and the other begins).
 
  As far as I am concerned, the above is normal operation for
most protocols, including IETF protocols, and do not need to 
be expressed in an explicit requirement (e.g. many of the behaviours
of TCP could be defined as being pre-emptive).
 
Gary

-----Original Message-----
From: Behcet Sarikaya [mailto:[email-masked]]
Sent: April 10, 2002 14:32
To: [email-masked]
Subject: Re: [NSIS] attempted summary of pre-emption thread

Gary Kenward wrote:

Martin:

  Getting clearer to me. This would seem to be a state machine design
issue. One could define requirements that certain protocol events
were asynchronous, thus distinguishing them from the synchronous protocol
events, and require certain behaviours on the part of the communicating 
entities. In general, the normal assumption for the Internet is asynchronous
message, as ensuring synchronization (implying assured delivery, ordering, 
and no duplication) is often more complex (this is my perception, I am open
to correction on this). There are not many precedents for signalling in the
Internet.

  The other observation I would make is that the IETF does not specify
state machine behaviour, but rather protocol behaviour.

Gary, what makes you say this? The state machine behaviour is part of
protocol behavior. Protocol RFCs specify the behavior informally which makes
it rather difficult to fully specify the state machine behavior more
difficult than if the specs were in SDL. But that does not mean the state
machine behavior is not or can not be specified.

Thus, the requirement
for a message arrival at a node is usually an outcome at the node, and 
a (possible) response to the message. How the node effects the outcome and
generates the response is left to the node designer. Thus, in general,
one would not require that a state-machine be pre-empted by a protocol
event.

  Marcus was correct in his posting that there is confusion over the topic
here. Perhaps the confusion was mine, but my recollection is that this 
thread started with a discussion of "pre-emption" bits in NSIS to specify
flow
treatment. This issue with the protocol state machine is very different.

  My view, and this is just my view, is that specifying state-machine
pre-emption
is not the right requirement (in the IETF context). Rather, we should focus
on
the expected outcome of a protocol exchange and the dependence or
independence
of the sequencing of messages.

  Otherwise, I agree that it must be (and usually, btw, is) accounted for in
the protocol definition.

Regards,
Gary

--behcet

---

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

Robert, 

I am in complete agreement with what you say below and in particular I think
that we document these non-requirements in an ongoing basis to show how the
NSIS protocol transparently supports them.

Marco

> Sent: Tuesday, April 09, 2002 9:06 AM
> To: [email-masked]

---

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 11 Apr 2002 08:36:17 +0200

Hello Martin,

> 6) (optional) remote end sends tear confirmation

For my clarification: the initiator signals to all units in parallel?
If no, then sequential signaling is applied. In the case of 
sequential signaling, a tear down of one network entity ends the 
reservation (tear down is propagated uplink, no further action 
downlink, all messages are synchronus).
If your scenario only holds for parallel signaling, then it's a 
special case, not a general requirement. I'd have more comments on 
parallel signalling (which are not related to pre-emption) and would 
like to ask for confirmation that that's what you are suggesting.

Regards, Rüdiger

---

From: Martin Karsten <[email-masked]>
Date: Thu, 11 Apr 2002 16:50:44 +0200 (CEST)

> like to ask for confirmation that that's what you are suggesting.

The dummy protocol above was not meant as suggestion at all, but just as a
very simplified (and probably unrealistic) example for illustration only. I
don't think that it makes sense to further discuss it.

Martin