Subject: [PCN] I-D ACTION:draft-chan-pcn-problem-statement-00.txt

From: [email-masked] (by way of Kwok Ho Chan <[email-masked]>)
Date: Mon, 18 Sep 2006 10:29:11 -0400

FYI.
The Problem Statement draft is available at the IETF draft servers.
-- Kwok --

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Pre-Congestion Notification Problem Statement
	Author(s)	: K. Chan, et al.
	Filename	: draft-chan-pcn-problem-statement-00.txt
	Pages		: 16
	Date		: 2006-9-15
	
DiffServ mechanisms have been developed to support Quality of Service
(QoS).  However, the level of assurance that can be provided with
DiffServ without substantial over-provisioning is limited.  Pre-
Congestion Notification (PCN) investigates the use of per-flow
admission control to provide the required service guarantees for the
admitted traffic.  While admission control will protect the QoS under
normal operating conditions, an additional flow pre-emption mechanism
is necessary in the times of heavy congestion (e.g. caused by route
changes due to link or node failure).

This document provides a problem statement on the addition of flow
admission control and flow pre-emption functionality to a DiffServ
network, in particular for the support of real time services such as
voice and video.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-chan-pcn-problem-statement-00.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the
username "anonymous" and a password of your e-mail address. After
logging in, type "cd internet-drafts" and then
"get draft-chan-pcn-problem-statement-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-chan-pcn-problem-statement-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-chan-pcn-problem-statement-00.txt

<ftp://ftp.ietf.org/internet-drafts/draft-chan-pcn-problem-statement-00.txt>
_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

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

---

From: ken carlberg <[email-masked]>
Date: Mon, 18 Sep 2006 14:35:23 -0400

Part of your problem statement advocates the use of preemption of  
flows as an option to maintain QoS of other existing flows when  
severe congestion (possibly through node failure occurs).

Back in April, I posted a review of draft-briscoe-tsvwg-cl- 
architecture-02.txt and asked if an additional model or approach  
could be taken in place of preemption.  The specific comments can be  
found at:

(me)  http://www1.ietf.org/mail-archive/web/tsvwg/current/msg06369.html.
(bob) http://www1.ietf.org/mail-archive/web/tsvwg/current/msg06396.html

In that thread I pointed the authors to another work in progress as  
one example that added the approach of engineered spare capacity  
instead of preemption.  (fyi, the latest version of the suggested  
reading is: ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft- 
lefaucheur-emergency-rsvp-02.txt).  And in looking at the outline of  
draft-briscoe-tsvwg-cl-architecture-03.txt, it appears that the  
authors are still just focusing on preemption.  (quite  
understandable, because what I suggested is significant and not  
easily added in a single rev).

The reason I ask if your effort can consider another model other than  
preemption is that for certain deployments of VoIP in countries, like  
the U.S. and Germany, non-man-in-the-loop preemption is not allowed.   
This would seem to severely limit the actions you advocate during  
times of severe congestion, albeit for one type of flow.

So while there isn't necessarily a technical concern in using  
preemption, unfortunately the realities of regulation and laws would  
seem to encourage your proposed group to consider additional  
alternatives.

-ken

---

From: "Jozef Babiarz" <[email-masked]>
Date: Tue, 19 Sep 2006 09:21:00 -0400

Ken thanks for your comments.
Yes, there maybe other options or action that can be taken besides
pre-emption.
1./ The routers can signal pre-congestion level(s) via ECN bits in IP
header to egress hosts and egress hosts really this information to
ingress hosts to reduce their sending rate if they can (use a lower rate
codec). However, this does not totally solve the problem.
2./ The network is engineered so that there are sufficed spare resources
available that should a router or link fail, that traffic is rerouted on
to the spare resources. Again this does not totally solve the problem
because there maybe multiple failures, etc. 

Pre-emption is the last resort mechanism that removes real-time
inelastic flows to bring that service class back into non-congested
state.  It will be interesting what guidelines/rules the FCC and other
regulatory bodies will provide/use should an operator be forced to
preempt m number of voice flows in the IP network? My take is that it
would be similar to what is done in TDM networks today when a TDM switch
or trunk fails and calls are lost.   

Regards, Joe
QoS & Network Architecture
Telephone: 613-763-6098 (ESN 393-6098)
Email: [email-masked]

-----Original Message-----
From: ken carlberg [mailto:[email-masked]] 
Sent: Monday, September 18, 2006 2:35 PM
To: by way of Kwok Ho Chan <[email-masked]>
Cc: [email-masked]
Subject: Re: [PCN] I-D ACTION:draft-chan-pcn-problem-statement-00.txt

-ken

---

From: <[email-masked]>
Date: Tue, 19 Sep 2006 14:35:43 +0100

Ken

Thanks for your comments. Trying to work out how to deal with them, as
the set of docs will evolve following on from the PCN BoF. 

Do we need to change the problem statement?
Should we add near the end of Section 1.1, where flow pre-emption is
mentioned, a comment something like?:

Such a flow pre-emption mechanism is complementary to the techniques
described in draft-lefaucheur-emergency-rsvp-02.txt [*]. Note that
sometimes flow pre-emption is not appropriate, for policy or regulatory
reasons. For example, for certain deployments of VoIP in the U.S. and
Germany regulation does not allow non-man-in-the-loop pre-emption [**].

What do you reckon?

[*] is this ok? Do you see them as complementary mechanisms? My reading
is that both could be appropriate, depending on the circumstances. Also
that draft-lefaucheur-emergency-rsvp applies to 'normal' circumstances,
whereas flow pre-emption is targeted at 'abnormal' circumstances eg
where several nodes have failed causing much less network capacity (so
re-routing has overloaded some links).

[**] just to clarify what this means - pre-emption is only allowed if a
human explicitly authorises the pre-emption of a particular flow;
automatic pre-emption by the network isn't allowed. This applies where
the end user is getting a PSTN service.

I don't think we need to change the Draft Charter
http://standards.nortelnetworks.com/pcn/PCN_draft_charter_v00.txt
and the standards-track docs won't need to mention this issue. 
But at least one deployment model draft should mention it, saying it's a
complementary technique etc. 
is this ok? or do you think there are interactions between the two
techniques that we need to explore, or something that needs to be added
to the Charter?

Thanks
phil

-----Original Message-----
From: ken carlberg [mailto:[email-masked]] 
Sent: 18 September 2006 19:35
To: by way of Kwok Ho Chan <[email-masked]>
Cc: [email-masked]
Subject: Re: [PCN] I-D ACTION:draft-chan-pcn-problem-statement-00.txt

-ken

---

From: ken carlberg <[email-masked]>
Date: Tue, 19 Sep 2006 09:58:05 -0400

Joe,

> because there maybe multiple failures, etc.

understood.  perhaps in the next iteration of the architecture  
document these can be more prominently placed/discussed so that it is  
seen as the same "level" as preemption.

> or trunk fails and calls are lost.

well, within the context of the US PSTN, when such a condition exists  
and calls are lost, other existing calls on other switches are not  
preempted when the system tries to re-establish lost calls.  When  
capacity has reached its limit, additional call attempts are blocked.

maybe we have a different perspective of preemption.  as I view it,  
preemption is removing *existing* state (circuit in the PSTN world)  
in favor of new state.  In the US and some other countries, this is  
not allowed in the PSTN.  I also don't claim to be an expert on the  
FCC, but recent rulings regarding 911 service for certain VoIP  
providers would seem that they intend to extend existing regulations  
from PSTN to certain VoIP providers.

-ken

---

From: "Kwok-Ho Chan" <[email-masked]>
Date: Tue, 19 Sep 2006 09:58:51 -0400

Ken:
Thank you very much for your suggestions.

We are looking into different ways of reducing the offered traffic 
load to the network
during different detected levels of congestions.

The approach we are taking is to separate the DETECTION from the (RE)ACTION.

The DETECTION mechanism does not dictate the use of PREEMPTION, just the
need to reduce the offered traffic load to the congested portions of 
the network.
We called this Preemption Marking.
May be this terminology cause confusion?

The (RE)ACTION mechanism may or may not require PREEMPTION.
And how this is done depends on the Deployment Model.
draft-briscoe-tsvwg-cl-architecture-xx.txt is one of the Deployment 
Models we are working on.
We are working on another Deployment Model where a tighter 
integration with applications
may allow differing (RE)ACTIONs to be deployed based on the scenario 
of deployment.

But the draft-chan-pcn-problem-statement-00.txt does give the example 
of the use of
Preemption in the MLPP scenario.  We should indicate in the Problem 
Statement draft
the issue of reducing the offered traffic load to the congested 
portions of the network
without the use of active call (session) preemption.

I will add this to the Issues List document I have at:
http://standards.nortel.com/pcn/ProblemStatementDraftIssuesList.txt

With one issue (Issue A.4) under the Terminology Issues section (A).
And one issue (Issue B.9) under the Environmental Issues sedtion (B).

We are trying to not indicate solutions in the Problem Statement draft.
Hence the (RE)ACTION of Preemption should be discussed in each
of the Deployment Model drafts.  There may be more than one solution.

I will try to address these issues in the next version of the Problem 
Statement draft.

We should also discuss the different requirements of the Preemption concept
to assist better Deployment Model drafts.

Thanks!
-- Kwok --

---

From: ken carlberg <[email-masked]>
Date: Tue, 19 Sep 2006 10:25:56 -0400

Phil,

> Do we need to change the problem statement?

I wouldn't change the draft at this time.  just consider my comment  
at the upcoming BoF

> Germany regulation does not allow non-man-in-the-loop pre-emption  

I don't know if its necessary to point to a specific approach.  i  
think simply presenting the basics   (eg, paraphrasing) some of the  
key points written in the lefaucheur-emergency draft on engineering  
spare capacity would be helpful.

> re-routing has overloaded some links).

well, I see the discussions in the appendix and its potential modes  
of operation/deployment of draft-lefaucheur-emergency-rsvp as being  
something constructive to your draft.  the body of the lefaucheur  
draft has potential to be complimentary to your work in the same  
context as your related work on MPLS.  I'm not sure that I see a  
difference in circumstances: my feeling is that both have their  
interest in abnormal conditions.  What may be different are motivations.

> the end user is getting a PSTN service.

yes, for the US and Germany (and some other countries).  There are  
cases where a person contacts the human operator to interrupt or  
break a call (the man-in-the-loop action).  But automated preemption  
through signaling is not allowed in many jurisdictions/governments.   
The one exception, to my understanding, is Japan which does allow a  
measure of preemption for 911-type calls.

> techniques that we need to explore, or something that needs to be  

i think I covered these questions above.

cheers,

-ken

---

From: ken carlberg <[email-masked]>
Date: Tue, 19 Sep 2006 10:35:22 -0400

> The approach we are taking is to separate the DETECTION from the  

cool.

> need to reduce the offered traffic load to the congested portions  
> of the network.

yes, it is if there are other (re)actions other than preemption.   
maybe something generic like "Action Marking".  any other term is  
fine so long as it doesn't direct me the reader into a single form of  
a solution.

-ken

---

From: "Jozef Babiarz" <[email-masked]>
Date: Tue, 19 Sep 2006 10:54:15 -0400

Ken,
There at least two types of preemption as, I see it.
One is when that configured bandwidth for that service on the path is
fully utilized and there is a need to admit additional higher precedence
voice flow, so the network preempts a lower precedence voice flow to
make room. This is similar to MLPP capability in TDM voice networks. 

The second usage of preemption is to protect the service class when
there are network failures (router and or link). In this case, I believe
that the IP network provides additional capability of rerouting traffic
quickly when a path fails versus just dropping the voice channels as is
done in TDM when switch fails. When rerouting of voice flows on
detection of failures, there maybe situations that the remaining working
network links do not have enough capacity to forward all the voice flows
and provide good QoS, therefore some voice flows may need to be
preempted. 

Finally, operators do have the option of just using admission control
not supporting preemption in their network.   

Regards, Joe

-----Original Message-----
From: ken carlberg [mailto:[email-masked]] 
Sent: Tuesday, September 19, 2006 9:58 AM
To: Babiarz, Jozef (CAR:0S03)
Cc: [email-masked]
Subject: Re: [PCN] draft-chan-pcn-problem-statement-00.txt

Joe,

-ken

---

From: "Kwok-Ho Chan" <[email-masked]>
Date: Tue, 19 Sep 2006 11:26:08 -0400

Thanks!
Please see the updated issues list (with Issues A.4 and B.9) at:
http://standards.nortel.com/pcn/ProblemStatementDraftIssuesList.txt

It seems you are agreeing with the approach we are taking.
But we still need to work out some of the details.

-- Kwok --