Subject: [PCN] I-D Action:draft-ietf-pcn-architecture-04.txt

From: [email-masked]
Date: Mon, 14 Jul 2008 15:00:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Congestion and Pre-Congestion Notification Working Group of the IETF.

	Title           : Pre-Congestion Notification Architecture
	Author(s)       : P. Eardley
	Filename        : draft-ietf-pcn-architecture-04.txt
	Pages           : 52
	Date            : 2008-07-14

The purpose of this document is to describe a general architecture
for flow admission and termination based on pre-congestion
information in order to protect the quality of service of established
inelastic flows within a single DiffServ domain.Status

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pcn-architecture-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: <[email-masked]>
Date: Tue, 15 Jul 2008 08:31:09 +0100

I updated the Architecture draft.

There are no major changes, but several more minor ones. These mostly
reflect the consensus call about PCN-marking (as reflected in
[I-D.eardley-pcn-marking-behaviour]), and the current decisions about
encoding (as reflected in [I-D.moncaster-pcn-baseline-encoding] and
[I-D.moncaster-pcn-3-state-encoding]). I also did some slight
re-structuring and editing to try and improve the clarity, especially of
the introductory material and the High level architecture (where I also
added a sub-section on backwards compatibility with respect to
[RFC4774]). I also took account of all the comments received on the -03
version (thanks for them)

Comments welcome! - thanks,
phil

{ -----Original Message-----
{ From: [email-masked] [mailto:[email-masked]] On Behalf Of
{ [email-masked]
{ Sent: 14 July 2008 23:00
{ To: [email-masked]
{ Cc: [email-masked]
{ Subject: [PCN] I-D Action:draft-ietf-pcn-architecture-04.txt
{ 
{ A New Internet-Draft is available from the on-line Internet-Drafts
{ directories.
{ This draft is a work item of the Congestion and Pre-Congestion
{ Notification Working Group of the IETF.
{ 
{ 
{ 	Title           : Pre-Congestion Notification Architecture
{ 	Author(s)       : P. Eardley
{ 	Filename        : draft-ietf-pcn-architecture-04.txt
{ 	Pages           : 52
{ 	Date            : 2008-07-14
{ 
{ The purpose of this document is to describe a general architecture
{ for flow admission and termination based on pre-congestion
{ information in order to protect the quality of service of established
{ inelastic flows within a single DiffServ domain.Status
{ 
{ A URL for this Internet-Draft is:
{ http://www.ietf.org/internet-drafts/draft-ietf-pcn-architecture-04.txt
{ 
{ Internet-Drafts are also available by anonymous FTP at:
{ ftp://ftp.ietf.org/internet-drafts/
{ 
{ Below is the data which will enable a MIME compliant mail reader
{ implementation to automatically retrieve the ASCII version of the
{ Internet-Draft.
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: <[email-masked]>
Date: Tue, 15 Jul 2008 10:02:09 +0100

I spotted a couple of small corrections needed:

In S6.2, Flow termination
Exactly how the flow termination decision is made will be defined
   separately in informational documents.  At a high level several
   approaches are proposed:
...
   o  Another approach monitors PCN-packets and terminates any PCN-flow
      with an excess-traffic-marked packet.  Compared with the
      approaches above, PCN-marking needs to be done at a reduced rate
      (every "s" bytes of excess traffic) otherwise far too much traffic
      would be terminated.

This bullet needs to be changed, as it's inconsistent with the consensus
decisions about marking algorithm. The equivalent approach can be
achieved by randomly selecting some fraction of the marked packets for
termination (as in http://tools.ietf.org/id/draft-menth-pcn-emft-00.txt)

In S2 Terminology
The last sentence of both PCN-threshold-rate & PCN-excess-rate
definitions needs to be deleted (they don't apply in the single marking
case). 

In addition I think it would be helpful to add a couple of pics to
illustrate what PCN-threshold-rate & PCN-excess-rate mean in terms of
when admission and termination are done. Similar to Fig 1 in
http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/Menth08
-PCN-Comparison.pdf - one for the case with 3 encoding states, and one
for single marking.

phil

{ -----Original Message-----
{ From: [email-masked] [mailto:[email-masked]] On Behalf Of
{ [email-masked]
{ Sent: 15 July 2008 08:31
{ To: [email-masked]
{ Subject: [PCN] New version of draft-ietf-pcn-architecture-04.txt
{ 
{ I updated the Architecture draft.
{ 
{ There are no major changes, but several more minor ones. These mostly
{ reflect the consensus call about PCN-marking (as reflected in
{ [I-D.eardley-pcn-marking-behaviour]), and the current decisions about
{ encoding (as reflected in [I-D.moncaster-pcn-baseline-encoding] and
{ [I-D.moncaster-pcn-3-state-encoding]). I also did some slight
{ re-structuring and editing to try and improve the clarity, especially
of
{ the introductory material and the High level architecture (where I
also
{ added a sub-section on backwards compatibility with respect to
{ [RFC4774]). I also took account of all the comments received on the
-03
{ version (thanks for them)
{ 
{ Comments welcome! - thanks,
{ phil
{ 
{ { -----Original Message-----
{ { From: [email-masked] [mailto:[email-masked]] On Behalf
Of
{ { [email-masked]
{ { Sent: 14 July 2008 23:00
{ { To: [email-masked]
{ { Cc: [email-masked]
{ { Subject: [PCN] I-D Action:draft-ietf-pcn-architecture-04.txt
{ {
{ { A New Internet-Draft is available from the on-line Internet-Drafts
{ { directories.
{ { This draft is a work item of the Congestion and Pre-Congestion
{ { Notification Working Group of the IETF.
{ {
{ {
{ { 	Title           : Pre-Congestion Notification Architecture
{ { 	Author(s)       : P. Eardley
{ { 	Filename        : draft-ietf-pcn-architecture-04.txt
{ { 	Pages           : 52
{ { 	Date            : 2008-07-14
{ {
{ { The purpose of this document is to describe a general architecture
{ { for flow admission and termination based on pre-congestion
{ { information in order to protect the quality of service of
established
{ { inelastic flows within a single DiffServ domain.Status
{ {
{ { A URL for this Internet-Draft is:
{ {
http://www.ietf.org/internet-drafts/draft-ietf-pcn-architecture-04.txt
{ {
{ { Internet-Drafts are also available by anonymous FTP at:
{ { ftp://ftp.ietf.org/internet-drafts/
{ {
{ { Below is the data which will enable a MIME compliant mail reader
{ { implementation to automatically retrieve the ASCII version of the
{ { Internet-Draft.
{ _______________________________________________
{ PCN mailing list
{ [email-masked]
{ https://www.ietf.org/mailman/listinfo/pcn
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 17 Jul 2008 12:33:06 +0100

Phil,

THanks for updating the arch. Looks good.

Below are some suggested minor corrections. In general, there's less 
uncertainty, which is good. Some of the points below open up 
possibilities for future variation just a little, where I think we 
don't need to be so prescriptive.

[Next mail, I'll re-open the only slightly controversial issue I 
believe is left.]

>4. Deployment scenarios
>{...}
>I is possible that a user wants its inelastic traffic to use the PCN
>based on defined rules, in reaction to pre-congestion. mechanisms 
>but also react to ECN marking outside the PCN-domain
>[I-D.sarker-pcn-ecn-pcn-usecases]. Two ways to do this are to tunnel
>all PCN-packets across the PCN-domain, so that the ECN marks is
>carried transparently across the PCN-domain, or to use the three
>state PCN encoding [I-D.moncaster-pcn-3-state-encoding]. This is
>discussed further in Section Section 7.

s/Two ways/Two possible ways/
{Removes ambiguity of intent. Making it clear this doesn't mean these 
are the two recommended ways, or the only two allowed ways.}

s/This is discussed further in Section Section 7
  /This is discussed further in Section 7.1 on Tunnelling/

>4. Deployment scenarios
>{...}
>The possibility of deploying just one of PCN's flow admission and
>    termination mechanisms is certainly an option when only two PCN
>    encoding states are available

s/when only two PCN encoding states are available
  /when an operator chooses to use up only two encoding states for PCN/

>5.2. Assumption 2: Real-time applications {...}
>As a consequence, it is assumed that PCN-marking is being applied to
>traffic scheduled with the expedited forwarding per-hop behaviour,
>[RFC3246], or traffic with similar characteristics.

s/traffic with/a PHB with/

>6. High-level functional architecture
>{...}
>    the operator may have two or three encoding states
>    available.  In both cases the ECN field is set to 11 to indicate PCN-
>    marking.  In the former case, one DSCP is used.  In the latter case a
>    second DSCP is used,
>

Suggested new text:
...the operator may *choose to use* two or three encoding states. 
With current tunnelling behaviour (RFC3168 or RFC4301), only the CE 
(11) codepoint of the ECN field survives decapsulation. So the ECN 
field *can currently only be* set to 11 to indicate PCN-marking. For 
the two-state case, one DSCP can be used.  For the three-state case a 
second DSCP seems necessary,

Reasoning: I think the text as written was too prescriptive for an 
architecture document. If one day we get the unnecessarily 
restrictive ECN tunnelling behaviour changed we would then be able to 
use 01 and 10 as well. Then we won't need to only be restricted to 11

If we can fully work out how at least some of 
[ID.menth-pcn-psdm-encoding] could be standardised, we ought to 
mention that here too. Or at least allow for some post-standards 
innovation in this space.

>Flow admission and flow termination when there are only two PCN
>encoding states{...}
>If a PCN-domain has only two encoding states available {...}

Suggested new text:
If an operator chooses to use only two PCN encoding states {...}

>6.5. PCN-traffic
>{...}
>       However, a PCN-node should dedicate some capacity to lower
>       priority traffic so that it isn't starved.  Such traffic doesn't
>       contribute to the PCN meters.
Suggest we add: (however, there are valid proposals where some does 
[Songhurst])

Bob

>{ { implementation to automatically retrieve the ASCII version of the

____________________________________________________________________________
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: Thu, 17 Jul 2008 12:49:34 +0100

Thanks bob,
I'll work these in the -05 version. I think it best to avoid discussing
tunnelling at the start of S6, but I'll get in the sentiment of your
comment.

phil

{ -----Original Message-----
{ From: Briscoe,RJ,Bob,XVR9 BRISCORJ R
{ Sent: 17 July 2008 12:33
{ To: Eardley,PL,Philip,CXR9 R
{ Cc: [email-masked]
{ Subject: Re: [PCN] New version of draft-ietf-pcn-architecture-04.txt
{ 
{ Phil,
{ 
{ THanks for updating the arch. Looks good.
{ 
{ Below are some suggested minor corrections. In general, there's less
{ uncertainty, which is good. Some of the points below open up
{ possibilities for future variation just a little, where I think we
{ don't need to be so prescriptive.
{ 
{ [Next mail, I'll re-open the only slightly controversial issue I
{ believe is left.]
{ 
{ 
{ >4. Deployment scenarios
{ >{...}
{ >I is possible that a user wants its inelastic traffic to use the PCN
{ >based on defined rules, in reaction to pre-congestion. mechanisms
{ >but also react to ECN marking outside the PCN-domain
{ >[I-D.sarker-pcn-ecn-pcn-usecases]. Two ways to do this are to tunnel
{ >all PCN-packets across the PCN-domain, so that the ECN marks is
{ >carried transparently across the PCN-domain, or to use the three
{ >state PCN encoding [I-D.moncaster-pcn-3-state-encoding]. This is
{ >discussed further in Section Section 7.
{ 
{ s/Two ways/Two possible ways/
{ {Removes ambiguity of intent. Making it clear this doesn't mean these
{ are the two recommended ways, or the only two allowed ways.}
{ 
{ s/This is discussed further in Section Section 7
{   /This is discussed further in Section 7.1 on Tunnelling/
{ 
{ 
{ >4. Deployment scenarios
{ >{...}
{ >The possibility of deploying just one of PCN's flow admission and
{ >    termination mechanisms is certainly an option when only two PCN
{ >    encoding states are available
{ 
{ s/when only two PCN encoding states are available
{   /when an operator chooses to use up only two encoding states for
PCN/
{ 
{ >5.2. Assumption 2: Real-time applications {...}
{ >As a consequence, it is assumed that PCN-marking is being applied to
{ >traffic scheduled with the expedited forwarding per-hop behaviour,
{ >[RFC3246], or traffic with similar characteristics.
{ 
{ s/traffic with/a PHB with/
{ 
{ 
{ >6. High-level functional architecture
{ >{...}
{ >    the operator may have two or three encoding states
{ >    available.  In both cases the ECN field is set to 11 to indicate
PCN-
{ >    marking.  In the former case, one DSCP is used.  In the latter
case a
{ >    second DSCP is used,
{ >
{ 
{ Suggested new text:
{ ...the operator may *choose to use* two or three encoding states.
{ With current tunnelling behaviour (RFC3168 or RFC4301), only the CE
{ (11) codepoint of the ECN field survives decapsulation. So the ECN
{ field *can currently only be* set to 11 to indicate PCN-marking. For
{ the two-state case, one DSCP can be used.  For the three-state case a
{ second DSCP seems necessary,
{ 
{ Reasoning: I think the text as written was too prescriptive for an
{ architecture document. If one day we get the unnecessarily
{ restrictive ECN tunnelling behaviour changed we would then be able to
{ use 01 and 10 as well. Then we won't need to only be restricted to 11
{ 
{ If we can fully work out how at least some of
{ [ID.menth-pcn-psdm-encoding] could be standardised, we ought to
{ mention that here too. Or at least allow for some post-standards
{ innovation in this space.
{ 
{ >Flow admission and flow termination when there are only two PCN
{ >encoding states{...}
{ >If a PCN-domain has only two encoding states available {...}
{ 
{ Suggested new text:
{ If an operator chooses to use only two PCN encoding states {...}
{ 
{ >6.5. PCN-traffic
{ >{...}
{ >       However, a PCN-node should dedicate some capacity to lower
{ >       priority traffic so that it isn't starved.  Such traffic
doesn't
{ >       contribute to the PCN meters.
{ Suggest we add: (however, there are valid proposals where some does
{ [Songhurst])
{ 
{ 
{ 
{ Bob
{ 
{ At 10:02 15/07/2008, [email-masked] wrote:
{ >I spotted a couple of small corrections needed:
{ >
{ >In S6.2, Flow termination
{ >Exactly how the flow termination decision is made will be defined
{ >    separately in informational documents.  At a high level several
{ >    approaches are proposed:
{ >...
{ >    o  Another approach monitors PCN-packets and terminates any
PCN-flow
{ >       with an excess-traffic-marked packet.  Compared with the
{ >       approaches above, PCN-marking needs to be done at a reduced
rate
{ >       (every "s" bytes of excess traffic) otherwise far too much
traffic
{ >       would be terminated.
{ >
{ >This bullet needs to be changed, as it's inconsistent with the
consensus
{ >decisions about marking algorithm. The equivalent approach can be
{ >achieved by randomly selecting some fraction of the marked packets
for
{ >termination (as in
http://tools.ietf.org/id/draft-menth-pcn-emft-00.txt)
{ >
{ >In S2 Terminology
{ >The last sentence of both PCN-threshold-rate & PCN-excess-rate
{ >definitions needs to be deleted (they don't apply in the single
marking
{ >case).
{ >
{ >In addition I think it would be helpful to add a couple of pics to
{ >illustrate what PCN-threshold-rate & PCN-excess-rate mean in terms of
{ >when admission and termination are done. Similar to Fig 1 in
{
>http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/Menth0
8
{ >-PCN-Comparison.pdf - one for the case with 3 encoding states, and
one
{ >for single marking.
{ >
{ >phil
{ >
{ >{ -----Original Message-----
{ >{ From: [email-masked] [mailto:[email-masked]] On Behalf
Of
{ >{ [email-masked]
{ >{ Sent: 15 July 2008 08:31
{ >{ To: [email-masked]
{ >{ Subject: [PCN] New version of draft-ietf-pcn-architecture-04.txt
{ >{
{ >{ I updated the Architecture draft.
{ >{
{ >{ There are no major changes, but several more minor ones. These
mostly
{ >{ reflect the consensus call about PCN-marking (as reflected in
{ >{ [I-D.eardley-pcn-marking-behaviour]), and the current decisions
about
{ >{ encoding (as reflected in [I-D.moncaster-pcn-baseline-encoding] and
{ >{ [I-D.moncaster-pcn-3-state-encoding]). I also did some slight
{ >{ re-structuring and editing to try and improve the clarity,
especially
{ >of
{ >{ the introductory material and the High level architecture (where I
{ >also
{ >{ added a sub-section on backwards compatibility with respect to
{ >{ [RFC4774]). I also took account of all the comments received on the
{ >-03
{ >{ version (thanks for them)
{ >{
{ >{ Comments welcome! - thanks,
{ >{ phil
{ >{
{ >{ { -----Original Message-----
{ >{ { From: [email-masked] [mailto:[email-masked]] On
Behalf
{ >Of
{ >{ { [email-masked]
{ >{ { Sent: 14 July 2008 23:00
{ >{ { To: [email-masked]
{ >{ { Cc: [email-masked]
{ >{ { Subject: [PCN] I-D Action:draft-ietf-pcn-architecture-04.txt
{ >{ {
{ >{ { A New Internet-Draft is available from the on-line
Internet-Drafts
{ >{ { directories.
{ >{ { This draft is a work item of the Congestion and Pre-Congestion
{ >{ { Notification Working Group of the IETF.
{ >{ {
{ >{ {
{ >{ {     Title           : Pre-Congestion Notification Architecture
{ >{ {     Author(s)       : P. Eardley
{ >{ {     Filename        : draft-ietf-pcn-architecture-04.txt
{ >{ {     Pages           : 52
{ >{ {     Date            : 2008-07-14
{ >{ {
{ >{ { The purpose of this document is to describe a general
architecture
{ >{ { for flow admission and termination based on pre-congestion
{ >{ { information in order to protect the quality of service of
{ >established
{ >{ { inelastic flows within a single DiffServ domain.Status
{ >{ {
{ >{ { A URL for this Internet-Draft is:
{ >{ {
{
>http://www.ietf.org/internet-drafts/draft-ietf-pcn-architecture-04.txt
{ >{ {
{ >{ { Internet-Drafts are also available by anonymous FTP at:
{ >{ { ftp://ftp.ietf.org/internet-drafts/
{ >{ {
{ >{ { Below is the data which will enable a MIME compliant mail reader
{ >{ { implementation to automatically retrieve the ASCII version of the
{ >{ { Internet-Draft.
{ >{ _______________________________________________
{ >{ PCN mailing list
{ >{ [email-masked]
{ >{ https://www.ietf.org/mailman/listinfo/pcn
{ >_______________________________________________
{ >PCN mailing list
{ >[email-masked]
{ >https://www.ietf.org/mailman/listinfo/pcn
{ 
{
________________________________________________________________________
__
{ __
{ Bob Briscoe, <[email-masked]>      Networks Research Centre, BT
{ Research
{ B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473
{ 645196
{

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Sun, 20 Jul 2008 15:22:40 +0000

Hi Phil

I have read the draft-ietf-pcn-architecture-04 and I have seen that there
are major changes included.
These major changes mainly affect the LC-PCN required features at the
interior and egress nodes.

I hope that the new version of the PCN architecture draft will include
the LC-PCN related features that were included in version 3 of the PCN
architecture draft and are removed in version 4 of the PCN architecture
draft.

Furthermore, I can not see any information about ingress-egress-aggregate
(trunl/pipe) model and HOSE model that has been intensivelly discussed
during the months after the IETF 71.

Best regards,
Georgios

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Sun, 20 Jul 2008 15:28:51 +0000

Dear all

I have read the drafts [I-D.eardley-pcn-marking-behaviour],
[I-D.moncaster-pcn-baseline-encoding] and
[I-D.moncaster-pcn-3-state-encoding> and
[draft-ietf-pcn-architecture-04] and I have seen that the LC-PCN related
features,
such as random dropping of marked and unmarked packets, use of
PCN_Affected_Marking encoding, use of egress based flow termination,
etc.  are not mentioned in these drafts.

I hope that this situation will be changed after the IETF 72 meeting.

Best regards,
Georgios

---

From: <[email-masked]>
Date: Tue, 22 Jul 2008 19:30:45 +0100

Georgios
 
you need to explain each feature in turn.
 
- dropping of marked and unmarked pkts was discussed extensively at last ietf. what the marking behaviour draft says is what the meeting decided. if you want this decision re-opened, evidence (or rather: new evidence) needs to be forthcoming. in fact, the agreement at the last ietf was that any evidence to re-opne the decisions would be far enough in advance of this ietf for us to assess it in advance of the meeting. 
- affected marking: a decision was made at last ietf about going forward with two encoding states (one dscp) in baseline and three encoding states (two dscps) in an Experimental extension. i guess you could propose a further experimental draft about affected marking.
- i'm not quite sure what you mean by egress based flow termination. but the architecture draft mentions different possibilities for where the flow termination decision might be made. 
 
thanks
phil

________________________________

From: [email-masked] on behalf of Georgios Karagiannis
Sent: Sun 20/07/2008 16:28
To: [email-masked]
Subject: [PCN] remarks on new drafts

Dear all

Best regards,
Georgios

---

From: <[email-masked]>
Date: Tue, 22 Jul 2008 19:31:17 +0100

i certainly didnt intend to make major changes. please point out what's been removed that needs re-inserting. 
 
not quite sure what you mean about the hose model. please remind me, a link to mailing list discussions would be good. i tried to reflect all mailing list discussions since the previous version, but easy to forget something!
 
thanks
phil

From: Georgios Karagiannis [mailto:[email-masked]]
Sent: Sun 20/07/2008 16:22
To: Eardley,PL,Philip,CXR9 R; [email-masked]
Subject: Re: [PCN] New version of draft-ietf-pcn-architecture-04.txt

Hi Phil

Best regards,
Georgios

---

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 24 Jul 2008 08:56:17 +0200

Phil,

I try to sum up my position on downgrading:

- if downgrading is applied, then to flows only.
- if per flow treatment is required, then it is 
  applicable at PCN ingress boundary nodes only.
  PCN core nodes perform DiffServ aggregate 
  conditioning only. 
- if a flow is demoted to Best Effort by a PCN 
  ingress boundary node, the reason is that it 
  did not keep the agreed rate or flowspec. 
  This is a per flow treatment rather than a 
  DiffServ treatment and (to me) MUST be done 
  if and only if it can be signaled by the 
  control plane of that flow. Otherwise that 
  flow MUST be policed to the agreed rate 
  or flow spec. To me, demotion to Best Effort 
  should be seen as a functionality of the 
  service using PCN, but not as a PCN
  functionality.

Arguments supporting my view have been given 
in one of my last mails, I don't want to 
repeat them here.

Regards,

Rudiger

---------- Michael wrote: ---------------------------------------

Hi,

when downgrading pcn packets or whole pcn flows using signaling for the 
pcn class in case of congestion, this means we introduce another 
possibly complex mechanism because pcn does not work properly. Under 
normal operation, we should not experience congestion, in case of 
failures we can use flow termination. That's all. If we don't use flow 
termination, we have to live with potential congestion or could fight it 
somehow, but I don't think this should be part of the pcn architecture.

Regards,

    Michael

-- 
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

---

From: "Jozef Babiarz" <[email-masked]>
Date: Sat, 26 Jul 2008 17:13:29 -0400

Phil, I'm in agreement with Ruediger on downgrading. 

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Geib, Ruediger
Sent: July 24, 2008 2:56 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [PCN] downgrading packets or flows ?

Phil,

Regards,

Rudiger

---------- Michael wrote: ---------------------------------------

Hi,

Regards,

    Michael