Subject: RE: Multiple PCN classes (was: Re: [PCN] Re: How to discuss WG scoping decisions in an RFC?)

From: "Jozef Babiarz" <[email-masked]>
Date: Thu, 9 Aug 2007 20:03:06 -0400

Bob, Michael,
In TSVWG about two years ago, it was decided that flow precedence
information and control of it is to be handle in higher layers and not
by the transport layer. 

I believe that if we have precedence and normal traffic in the network
that admission and flow termination of it is handled based on precedence
information that is provided via signalling (SIP) during session setup
or higher layers control protocol. The transport layer and the PCN
mechanism is not precedence aware.

Regards, Joe
email:[email-masked]
Telephone:613-763-6098
-----Original Message-----
From: Michael Menth [mailto:[email-masked]] 
Sent: July 25, 2007 8:54 AM
To: Bob Briscoe
Cc: PCN IETF list
Subject: Multiple PCN classes (was: Re: [PCN] Re: How to discuss WG
scoping decisions in an RFC?)

Hi Bob,

Bob Briscoe wrote:
>>> Regarding emergency use: the charter says:
>>>
>>>   (D) flows may have different precedence, but the applicability
>>>       of the PCN mechanisms for emergency use (911, GETS, WPS,
>>>       MLPP, etc.) is out of scope
>>>
>>> This could be interpreted in more than one way, but I interpret this
as
>>> saying that PCN-specific mechanisms will not take flow precedence
into
>>> account.  Which is a different than saying that PCN cannot be used
with
>>> flow setup protocols/mechanisms that take flow precedence into
account.
>>>
>>
>> As soon as we have multiple PCN classes it might be useful to think 
>> about flow precedence especially with regard to admission and 
>> termination priority. Equal treatment of flows means that a highly 
>> critical telemedicine application has the same probability to be 
>> terminated as a "relatively" uncritcical VoIP call in case of a 
>> disaster. I read the passage in the way that it's not our job to 
>> define mechanisms for emergency use, but it is not prohibited to 
>> extend PCN towards multiple classes with different requirements 
>> although this is not the first thing to do.
>
> Michael, just to warn against your use of the word 'extend' PCN.
>
> For the avoidance of doubt, I think Steve's saying it is NOT in scope 
> to extend PCN towards multiple classes with different requirements, 
> but it is in scope for PCN to use (ie refer out to) other mechanisms 
> that satisfy different emergency reqs, and similarly I guess it would 
> be in scope to prove PCN doesn't stop these other mechanisms working.
>
> If I'm right, the txt in this arch draft is misleading and should be 
> changed. The _applicability_ of PCN mechs for emergency use is in 
> scope, but PCN-specific mechs for emergency use are out of scope.

Sorry for using the word "extend", but I'm not sure whether I understand

your answer correctly. We had the discussion about coexistence of 
several PCN- and non-PCN classes already several times on the list and 
it seemed to me that is an unsolved issue so far. When I say "extend 
PCN" I mean adapting the currently discussed single-PCN-class mechanisms

to work in a multi-class environment with a pre-defined number of PCN 
classes. I do not talk about extending PCN for the need of specific 
applications.

The existence of multiple PCN classes has some impact on encoding and 
possibly also on metering and marking, so this is a question that should

be discussed before encoding is decided. As far as I can remember the 
general view was that the charter does not forbid several PCN classes, 
but it's not the first thing to be done. Are we in line or is your view 
that there is and will be only a single PCN class that is coupled with a

single PHB? Maybe this is an issue for discussion at the meeting, at 
least to me, the answer of that question is not clear.

Regards,

Michael

>
>
> Bob
>
>
>> Regards,
>>
>>    Michael
>>
>>>
>>> Regards,
>>>
>>> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>>> Steven Blake                <[email-masked]>
>>> Ericsson/Redback Networks               +1 919-472-9913
>>>
>>>
>>>
>>> _______________________________________________
>>> PCN mailing list
>>> [email-masked]
>>> https://www1.ietf.org/mailman/listinfo/pcn
>>>
>>
>> -- 
>> Dr. Michael Menth, Assistant Professor
>> University of Wuerzburg, Institute of Computer Science
>> Am Hubland, D-97074 Wuerzburg, Germany, room B206
>> phone: (+49)-931/888-6644, fax: (+49)-931/888-6632
>> mailto:[email-masked]
>> http://www3.informatik.uni-wuerzburg.de/research/ngn
>
>
________________________________________________________________________
____ 
>
> Bob Briscoe, <[email-masked]>      Networks Research Centre, BT 
> Research
> B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 
> 645196 

-- 
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/888-6644, fax: (+49)-931/888-6632
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn

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

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

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 10 Aug 2007 18:14:21 +0100

Joe,

>mechanism is not precedence aware.

What exactly do you mean by "the tsvwg decided"? I don't think the tsvwg 
(or the IETF) is in a position to decide how emergency services define the 
use of PHBs for emergencies. I would have thought this is an issue to be 
decided by governments and operators and there's no big standards 
implication whichever way they choose. Why would the IETF want or need to 
force a government's or operator's choice in this respect? The whole point 
of Diffserv is that the codepoints are there to be used as operators 
choose, with some standard ones.

Certainly I believe the DoD don't like identifying precendence traffic in 
the data plane, as it might make it easier to target an attack at certain 
data. But the DoD is but a small part of the possible policy space in this 
area.

In general, the IETF does vendor standards. If anyone was going to touch 
operational policy standards in the hot policy area of emergency services, 
I doubt very much it would be the IETF, which doesn't have the 
political/voting structures necessary for such a politically sensitive 
subject. Instead, I would imagine the IETF should produce protocols that 
cater for what seems a reasonable spectrum of likely policy choices.

There does seem to be a valid technical motivation for specifying 
precedence both at the session/signalling layer and in the data plane. 
While a disaster or some emergency is in progress, routing and signalling 
will be continually being disrupted and trying to stabilise, leading to 
possibly continual excess traffic at various points in the data plane. Even 
if the emergency services have the right to signalling precedence over 
other flows, if the emergency is characterised by persistent or continuing 
disruption (earthquakes, riots, wars, DoS attacks etc),  the emergency 
media may well still be unintelligible for extended periods while 
signalling is trying to deal with the storm. So in some operational 
regimes, data priority might be needed as well as signalling priority. To 
ensure precedence traffic floats on top of the persistently choppy waves of 
other traffic.

Even if there was data plane precedence, PCN would not have to be 
precedence-aware. But when designing PCN we have to be aware of the 
possible combinatorial codepoint expansion. If we insisted that PCN is 
encoded in 3 DSCPs (say), then anyone that wanted to use n DSCPs for EF, 
would have to set aside 3 x n DSCPs for PCN.

However, I admit, I know very little about operational practices or 
regulatory/military/emergency/government requirements around the world in 
this respect. I'm just saying it seems unlikely that every government in 
the world will have agreed on a signalling-only approach to precedence.

Anyone have any facts?

Bob

>least to me, the answer of that question is not clear.

____________________________________________________________________________
Bob Briscoe, <[email-masked]>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196

---

From: <[email-masked]>
Date: Wed, 15 Aug 2007 09:14:43 +0100

Regardless of the precedence issue for emergency/military use, there
still could be more than one PCN class. Ie can imagine an operator
offering 2 services, "important inelastic flows with PCN adm ctrl" and
"less important inelastic flows with PCN adm ctrl"

The architecture draft (currently) says:
   o  The PCN mechanisms may be applied to more than one traffic class
      (which are distinguished by DSCP).

> From: Bob Briscoe [mailto:[email-masked]]
> Sent: 10 August 2007 18:14
> To: Jozef Babiarz
> Cc: PCN IETF list
> Subject: RE: Multiple PCN classes (was: Re: [PCN] Re: How to discuss
> WGscoping decisions in an RFC?)
> 
> Joe,
> 
> ensure precedence traffic floats on top of the persistently choppy
waves
> of
__
> __

---

From: "Jozef Babiarz" <[email-masked]>
Date: Tue, 21 Aug 2007 00:27:45 -0400

[Joe] I agree that the PCN mechanisms may be applied to more than one
traffic class which is distinguished by DSCP. I thinks that will be
sufficient as emergency/military services with PCN are currently out of
scope with the charter of PCN WG.

Regards, Joe
email:[email-masked]
Telephone:613-763-6098

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: August 15, 2007 4:15 AM
To: [email-masked]; Babiarz, Jozef (CAR:0S03)
Cc: [email-masked]
Subject: RE: Multiple PCN classes (was: Re: [PCN] Re: How to discuss

waves