Subject: [PCN] Fwd: I-D Action:draft-chan-pcn-encoding-comparison-01.txt

From: "Kwok-Ho Chan" <[email-masked]>
Date: Mon, 19 Nov 2007 09:00:16 -0500

FYI, Updated PCN Encoding Comparison draft.
-- Kwok --

>To: [email-masked]
>Cc:
>From: [email-masked]
>Date: Mon, 19 Nov 2007 08:50:01 -0500
>X-Scan-Signature: 386e0819b1192672467565a524848168
>Subject: I-D Action:draft-chan-pcn-encoding-comparison-01.txt
>X-BeenThere: [email-masked]
>X-Mailman-Version: 2.1.5
>Reply-To: [email-masked]
>List-Id: i-d-announce.ietf.org
>List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>,
>  <mailto:[email-masked]?subject=unsubscribe>
>List-Archive: <http://www1.ietf.org/pipermail/i-d-announce>
>List-Post: <mailto:[email-masked]>
>List-Help: <mailto:[email-masked]?subject=help>
>List-Subscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>,
>  <mailto:[email-masked]?subject=subscribe>
>X-Spam-Score: 1.3
>X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on ertph000.nortel.com
>X-Spam-Tests: FORGED_RCVD_HELO=0.05,MIME_BOUND_NEXTPART=0.106,
>  NO_REAL_NAME=0.178,TO_CC_NOT_NORTEL=1
>X-DNSBL-Score: -50
>X-DNSBL-Servers: bl.nortel.com
>X-SMTP-HELO: megatron.ietf.org
>X-SMTP-MAIL-FROM: [email-masked]
>X-SMTP-RCPT-TO: 
>[email-masked],[email-masked],[email-masked],[email-masked],[email-masked],[email-masked],[email-masked],[email-masked],[email-masked],[email-masked]
>X-SMTP-PEER-INFO: odin.ietf.ORG [156.154.16.145]
>X-SMTP-REASON: PASSED
>X-SMTP-ID: 1195480342.03028435
>X-OriginalArrivalTime: 19 Nov 2007 13:51:59.0066 (UTC) 
>FILETIME=[5AC87BA0:01C82AB3]
>
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
>         Title           : Pre-Congestion Notification Encoding Comparison
>         Author(s)       : K. Chan, G. Karagiannis
>         Filename        : draft-chan-pcn-encoding-comparison-01.txt
>         Pages           : 18
>         Date            : 2007-11-19
>
>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 termination mechanism
>is necessary in the times of heavy congestion (e.g. caused by route
>changes due to link or node failure).
>
>Encoding and their transport are required to carry the congestion and
>pre-congestion information from the congestion and pre-congestion
>points to the decision points.  This document provides a survey of
>several encoding methods, using comparisons amongst them as a way to
>explain their strengths and weaknesses.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-chan-pcn-encoding-comparison-01.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-encoding-comparison-01.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-encoding-comparison-01.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-encoding-comparison-01.txt
>
>
><ftp://ftp.ietf.org/internet-drafts/draft-chan-pcn-encoding-comparison-01.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: <[email-masked]>
Date: Tue, 20 Nov 2007 11:29:35 -0000

Kwok, Georgios, all,

Here are some comments on this draft
http://www.ietf.org/internet-drafts/draft-chan-pcn-encoding-comparison-0
1.txt - it's much better than 00!
Sorry for the lengthy email
Thanks,
Phil/

1. Introduction
Good. 

2. Encoding requirements
First 2 paras good. 
last para /bullets can be improved & I do not agree with "A total of six
required encoding states". Suggested replacement:
<<
Different PCN-marking behaviour documents have suggested different
encoding states are needed (2, 3 or 4 of the ones below). In total, the
following possibilities have been suggested:

o  Not pre-congested Marking, for indication of No pre-Congestion 
o  Admission Marking, for indication of Flow Admission Information
o  Termination Marking, for indication of Flow Termination Information
o  Single Marking, for indication of pre-congestion Information
o  Affected Marking, also for indication of Flow Termination Information

In addition there must be a way of distinguishing PCN-packets (whether
PCN-marked or not) from non PCN-pkts.

NOTE:
o  Single Marking: this has been suggested by [ref]. a single marking is
used to indicate both admission and termination marking 
o  Affected Marking: this has been suggested by [ref]. Its suggestion is
that a PCN-node which is termin-marking some pkts (ie is in the
termin-marking state) encodes the rest of the PCN-pkts with the affected
marking.
o  the WG will select which of the 5 possible encoding states listed
will actually be supported, or if the choice is a deployment choice for
the operator or under the control of an OAM Configuration system option
(eg where an operator employs either adm-marking or termin-marking but
not both in the PCN-domain). 

a few words about the above. 
I think have to talk about single marking - calling it AM/TM in the
tables is confusing (for me). 
I think it's better to say there has to be a way of distinguishing
PCN-packets & non PCN-pkts, rather than saying there has to be an extra
encoding state. 
I don't think nonce cheater detection is relevant [I think you're
talking about ECN nonce. It's fair enough to talk at the appropriate
moments about loss of ECN info if the ECN field is used to encode PCN.
but I think it's confusing (and on occasions, in some of your encoding
tables, wrong] to list ECN nonce as a PCN encoding state. Or are you
suggesting a *PCN* nonce? (would seem this isn't needed, as PCN-domain
is trusted. However, maybe thinking about future extensions?)

New sub-section 2.2 
I wonder if it's worth introducing what will be the evaluation criteria,
eg:
How easy is it to support multiple PCN classes ?
Are there any interactions with ecmp?
Are there any interactions with ecn?
Codepoint shortage for mpls. 
etc

Section 3 Encoding options
The first few lines (before bullets) could be shortened to:
"There are various encoding options, which can be grouped by which
fields they use:"
You can add a note here that "using a different channel (e.g., IPFIX .."
is out of scope of WG. I believe this is agreed. Section 3.4 can
therefore be safely deleted. 

The list of abbreviations can be tweaked:
Add: 
SM single marking ; 
Not-pc [or something meaning 'not pre-congested']

Delete: Not-ce, NDS-CE 

Section 3.1+
Think the "ecn & dscp" [current 3.1] needs the most explanation, so I
don't think it should be done first. suggest swapping with 3.3.

3.1 ECN & DSCP:
I found the first part of this [before 3.1.1] too dense. I think more
options need to be listed. I think the terminology in the table is
confusing, replace:
-----------------------------------------------------------------------
| ECN Bits     ||    00    |    01    |    10    |    11    ||   DSCP
|
|==============++==========+==========+==========+==========++==========
|
| RFC 3168     || Not-ECT  |  ECT(1)  |  ECT(0)  |    CE    ||    NA
|
|==============++==========+==========+==========+==========++==========
|
| Option 1     ||    AM    |    NA    |    NA    |    TM    ||   PCN
|
|--------------++----------+----------+----------+----------++----------
|
| Option 2     || Not-PC   |    NA    |    NA    |    SM    ||   PCN
|
|--------------++----------+----------+----------+----------++----------
|
| Option 3     || NA       |Not-PC(A) | Not-PC(T)|    SM    ||   PCN
|
|--------------++----------+----------+----------+----------++----------
|
| Option 4      ......
 -----------------------------------------------------------------------

In Option 3 I tried to work out what you meant by ECT(A) & ECT(T). I
think you're saying that the PCN-ingress-node sets the pkt with a mix of
2 codepoints; and only Single Marking state is used to indicate
pre-congestion; a pcn-node that wants to adm mark a pkt then selects a
Not-PC(A) pkt and re-marks it to SM. Is that right? need to explain why
this might be useful. 

There was an option once mentioned [in a draft-briscoe-architecture I
think] of using a 2nd DSCP to indicate TM (or perhaps to indicate
Affected marking).

I also think you can talk separately about the Affected marking. In my
table, AFM can obviously be added to all 3 Options

I also think there's a separate series of options where you're trying to
preserve ECN information on an end-to-end basis whilst having PCN
running in some domain in the middle. And you don't want to solve this
by doing something else like tunnelling over the PCN-domain. I think
this needs separate discussion as the issues are different and quite
hard to think about. For instance, there are two separate cases: just
preserving the Not-CE & CE info, and also preserving the ECT-nonce info
[there are different levels of interest/deployment/standardisation].
So I think it would be better to have a separate section discussing
encoding options when ECN info needs to be preserved.

3.1.1
could expand with something like: 
For example, this means that PCN can easily be applied to multiple
classes. 

3.1.1.1, [RFC4774] interactions:
as well as the things you talk about, I thought [not sure though] that
4774 was concerned about "what happens if things go wrong", eg:
- a RFC4774 pkt gets accidentally dscp-re-marked to the pcn-dscp; a
PCN-ingress-node gets misconfigured so it allows a RFC4774 pkt in on the
pcn-dscp. Can anything nasty happen?
- a router in the PCN-domain misconfigures itself so it's
RFC3246-enabled (ie no longer PCN-enabled). Can anything nasty happen,
eg when PCN-marked pkts encounter this router?
- a PCN-egress-node gets misconfigured so it allows a pcn-marked pkt
'out' of the PCN-domain.

eg if the first case happens, may want to try to minimise the impact of
any ECN-CE pkts that therefore sneak in on the PCN class

3.1.2
"possibly adding complexity when tunneling of the PCN encoding is
required" - explain.

3.2 using ECN field
if I understand this case right, you're saying that you're NOT using a
different DSCP to distinguish PCN traffic from non-PCN traffic. Think
you need to make this really clear, as it's quite bizarre. However, as
draft-pcn-architecture says "There needs to be a way for a PCN-node to
distinguish PCN-traffic from non PCN-traffic" - I don't understand how
you propose to do this, although I could imagine an Option like this:
|==============++==========+==========+==========+==========++==========
|
| Option 1     ||  Not-CE  |   Not-PC |    SM    |    CE    ||   NA
|
|--------------++----------+----------+----------+----------++----------
|
One downside of this is that there can only be 1 PCN class [PHB]

basically I don't understand the table. 

3.3 DSCP
in table, I think you should change things like "PCN/AM/TM" to SM, eg:
-----------------------------------------------------------------------
| DSCP Bits || Original |Experimental 1 |Experimental 2 |Experimental 3
|
|===========++==========+===============+===============+===============
|
| Option 7  ||  Not-PC  |     SM        |      NA       |      NA
|
|-----------++----------+---------------+---------------+---------------
|

3.3.1 Benefits
" concerns raised in RFC 4774 [20] are not applicable" - pedantic point:
I think it's really that they should be easier to deal with [whether or
not they're applicable depends on whether a PCN-node knows how to
process a pkt with the ECN field set]

" all 4 DSCP encoding options depicted in Figure 3 can support the not
congested indication, PCN capable transport marking, the admission
control and flow termination encoding states." Don't understand this,
only true for options 9 & 10.

"In addition Option 8 and 10 can in addition support the ECMP solution."
Replace: "They support Affected marking, which [ref] says has benefits
if the PCN-domain operates ECMP multi-path routing"

additional benefit (and in my view the most significant): exptal dscps
are lightly standardised - limited rules on how you use them, largely up
to the operator.

3.3.2 Drawbacks
clarify by replacing 
"This type of encoding needs to use per PHB, in addition to the original
DSCP and depending on the encoding option used, one, two or three DSCP
values, respectivelly." 
With "This type of encoding needs to use, for each DS class (PHB) that
is PCN-enabled, 2 3 or 4 DSCP values, depending on the encoding option."

Clarify that you need this set of 2/3/4 dscp values for each class
that's PCN-enabled.

Clarify that particular issue for mpls [codepoint shortage]

"Furthermore, if the separation between the PCN traffic and non- PCN
traffic is required". According to draft-pcn-architecture S4.5, there is
no "if" about it.

last para repeats what already said. 

Major disadvantage: interactions with ECMP. ECMP algos can use a
packet's DSCP when deciding what interface to fwd it on. In a PCN-domain
running ECMP, for a flow which has some packets PCN-marked and some
unmarked. its packets will travel over more than one path. This may well
lead to mis-ordering.
To me, this means that the S3.3 DSCP option is a non-starter in any
PCN-domain that uses an ECMP algorithm that uses the DSCP. NB ECMP algos
are proprietary to router vendors, ie operator has poor control over
them.

S3.4 out of band channel - section can be safely deleted.

S5 Security implications
All these are I think covered by the draft-pcn-architecture, so can
safely delete everything. 

Frequent Typo:
None PCN capable => non PCN capable

---

From: "Kwok-Ho Chan" <[email-masked]>
Date: Tue, 20 Nov 2007 09:11:52 -0500

Phil:
Thank you very much for your comments.
You know I am not shy and will receive and work on the comments positively.
With Hope to get them shorter as we improve this draft. :)
Will work on each issue you indicated.
Thanks!
-- Kwok --

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 22 Nov 2007 07:08:03 +0000

Hi Phil

Thanks for your comments!

Please see in line!

Best regards,
Georgios

>not both in the PCN-domain).

Georgios: Agree with the above, except that Single Marking is vague,
since it could have different meaning for different situations. Insome
situations is used to identify AM and/or TM and in others is used to
identify AM and/or TM and a way to distinguish PCn packets from non
PCN-pkts.
But if the PCN WG is willing to include SM
is okay for me!

>is trusted. However, maybe thinking about future extensions?)

Georgios: The ECN nonce discussion is associated with Section 4.3 in:
http://www.ietf.org/rfc/rfc4774.txt?number=4774
We have to clarify this in the text.

>Codepoint shortage for mpls.

Georgios: You are right, we had such criteria in the previous version,
but they were skipped during this version. I think is important to
include criteria!
Are these 4 enough?

>therefore be safely deleted.

Georgios: Agree!
>Not-pc [or something meaning 'not pre-congested']

Georgios: The above can be applied if the PCN WG decides to use SM as
additional encoding state, see above.

>don't think it should be done first. suggest swapping with 3.3.

Georgios: Agree!

>options need to be listed. I think the terminology in the table is

Georgios: I think that this can be replaced if the PCN WG decides to use
SM as an additional state.

>Not-PC(A) pkt and re-marks it to SM. Is that right? need to explain why

Georgios: We will clarify this, but please note that the option is taken
from:
http://www.watersprings.org/pub/id/draft-briscoe-tsvwg-cl-phb-03.txt
In particular see Alternative 2 from the above given draft.

>think] of using a 2nd DSCP to indicate TM (or perhaps to indicate

Georgios: Agree!

>table, AFM can obviously be added to all 3 Options

Georgios: Agree!
>encoding options when ECN info needs to be preserved.

Georgios: Agree, but this is what we wanted to emphasize in Section
3.1.1.1!
We could provide a disussion on ECN tunelling though in an additional
section.
>For example, this means that PCN can easily be applied to multiple

Georgios: Okay!

>any ECN-CE pkts that therefore sneak in on the PCN class

Georgios: I think that the issues that you mentioned are related to Issue
4 given in Section 3.1.1.1. This means that it will be good if we will
work out Issue 4. At the moment we avoid the discussion of this issue in
the draft.

>"possibly adding complexity when tunneling of the PCN encoding is

Georgios: Agree!

>you propose to do this, although I could imagine an Option like this:

Georgios: We will clarify this, but please note that the option is taken
from:
http://www.watersprings.org/pub/id/draft-briscoe-tsvwg-cl-phb-03.txt
In particular see Alternative 2 and 5 from the above given draft.

>in table, I think you should change things like "PCN/AM/TM" to SM, eg:

Georgios: If the PCN WG decides to use SM as additional state then OKAY!

Georgios: I do not understand your argumentation:
IF ECN is not used within the PCN domain then the requirements imposed by
RFC 4774 do not apply!

>only true for options 9 & 10.
Georgios: Agree, needs editing!

>are lightly standardised - limited rules on how you use them, largely up

Georgios: Agree!

>Clarify that you need this set of 2/3/4 dscp values for each class

Georgios: Agree!
>Clarify that particular issue for mpls [codepoint shortage]

Georgios: Agree!
>traffic is required". According to draft-pcn-architecture S4.5, there is

Georgios: Agree!
>last para repeats what already said.

Georgios: Okay!
>PCN-domain that uses an ECMP algorithm that uses the DSCP. 

Georgios: well I do not see this as a disadvantage. However, what you
mention about having an ECMP algorithm that uses DSCP is relevant.
Thus what we can do is to include a sentence in that emphasizes that the
ECMP situation is solved only if the ECMP algorithm does not use DSCP
during the implementation of the equal cost multi path algorithm.

> NB ECMP algos

Georgios: I am not sure about the above! An operator could at least
disallow the ECN option.

>S3.4 out of band channel - section can be safely deleted.

georgios: Agree!
>safely delete everything.

Georgios: Agree!

>None PCN capable => non PCN capable

Georgios: Okay!

---

From: <[email-masked]>
Date: Thu, 22 Nov 2007 07:58:46 -0000

Hi,
Have extracted this issue as a separate thread.
The context of the discussion below is encoding PCN-markings into
different DSCPs (ie not touching the ECN field). Question is, if you do
this are there any nasty interactions with ECMP.
Any comments?
phil

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 22 Nov 2007 08:25:59 +0000

Hi all

I have seen that I made a typing error on the last sentence!
It should be:

Georgios: I am not sure about the above! An operator could at least
disallow the ECMP option.

Best regards,
Georgios

---

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 22 Nov 2007 09:39:49 +0100

Georgios,

if you want to convince Deutsche Telekom's backbone engineering team to 
turn off ECMP, you must offer them very convincing arguments. I'd 
suggest the PCN WG to expect or allow ECMP to be active within a 
PCN network, at least if is a carrier network.

Regards,

Rudiger

|Georgios: I am not sure about the above! An operator could at least
|disallow the ECMP option.
|
|Best regards,
|Georgios
|
|
|
|
|On 11/22/2007, "[email-masked]" <[email-masked]> wrote:
|
|>Hi,
|>Have extracted this issue as a separate thread.
|>The context of the discussion below is encoding PCN-markings into
|>different DSCPs (ie not touching the ECN field). Question is, 
|if you do
|>this are there any nasty interactions with ECMP.
|>Any comments?
|>phil
|>
|>> >
|>> >Major disadvantage: interactions with ECMP. ECMP algos can use a
|>> >packet's DSCP when deciding what interface to fwd it on. In a
|>PCN-domain
|>> >running ECMP, for a flow which has some packets PCN-marked and some
|>> >unmarked. its packets will travel over more than one path. This may
|>well
|>> >lead to mis-ordering.
|>> >To me, this means that the S3.3 DSCP option is a non-starter in any
|>> >PCN-domain that uses an ECMP algorithm that uses the DSCP.
|>> 
|>> Georgios: well I do not see this as a disadvantage. 
|However, what you
|>> mention about having an ECMP algorithm that uses DSCP is relevant.
|>> Thus what we can do is to include a sentence in that emphasizes that
|>the
|>> ECMP situation is solved only if the ECMP algorithm does 
|not use DSCP
|>> during the implementation of the equal cost multi path algorithm.
|>> 
|>> > NB ECMP algos
|>> >are proprietary to router vendors, ie operator has poor 
|control over
|>> >them.
|>> 
|>> Georgios: I am not sure about the above! An operator could at least
|>> disallow the ECN option.
|>> 
|>> 
|>>
|>
|>
|>_______________________________________________
|>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: <[email-masked]>
Date: Thu, 22 Nov 2007 10:57:25 -0000

Thanks Georgios - inline
phil

> -----Original Message-----

I don't think S4.3 is relevant (other sections are) as the scope of
Section 4.3 of 4774 is "The third option specified above is for the
alternate ECN semantics to be defined so that traffic using the
alternate semantics would coexist safely in the Internet on a path with
one or more old routers that use only the default ECN semantics."
Which seems not applicable as Assumption 1 of archit says "We assume
that the PCN-domain is a controlled environment, i.e. all the nodes in a
PCN-domain run PCN and trust each other." 

> In particular see Alternative 2 and 5 from the above given draft.

I had another read of phb-03 & found it a bit confusing. Basically these
options can be done either with a PCN-DSCP, or try & do in existing PHB
(which may already be being used for service that's using ECN e2e).
there needs to be some very careful explanation of the issues.

Case 1:
ECT nonce not being used e2e, ie concerned about impact on 00 & CE
codepoints. Need to think about what happens if pkt [1] arrives 00 &
gets PCN-marked, impact on ECN; [2] arrives CE, what's impact on PCN (&
on ECN if it can get re-marked)
Case 2:
ECT nonce is being used e2e, ie concerned about impact on all 4
codepoints.

> Georgios: If the PCN WG decides to use SM as additional state then
OKAY!

On 2nd thoughts, I'm not sure if introducing an SM encoding state is the
right ways of handling this. 

Really we have markings associated with the PCN-lower-rate &
PCN-upper-rate, so we should describe them as:
PCN-lower-rate-marking
PCN-upper-rate-marking
Single Marking is then an encoding scheme that only uses the first of
these.
This would be more accurate, although it would probably make it harder
for the reader to understand the draft.

On 2nd reading, what you said is clear.

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 22 Nov 2007 13:47:46 +0100

Hi Ruediger

An operator can however choose which type of ECMP algorithm 
should be used in its network, or?
Which types of ECMP algorithm is Deutsche Telecom using?

We have to clarify which types of ECMP algorithms will 
be affected when the DSCP is used for PCN purposes.

Not all the ECMP algorithms are affected. I am not sure about it but 
if the ECMP algorithms 
that are using DSCP to select packets for load sharing might not be affected
(when DSCP is used for 
PCN purposes) if the selection process in addition to DSCP also uses 
the 5 tuple (for flow identification).

Best regards,
Georgios

> From: Geib, Ruediger [mailto:[email-masked]] 
> Sent: donderdag 22 november 2007 9:40
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [PCN] Encoding PCN-markings into DSCPs - are 
> there anyinteractions with ECMP?
> 
> Georgios,
> 
> if you want to convince Deutsche Telekom's backbone 
> engineering team to turn off ECMP, you must offer them very 
> convincing arguments. I'd suggest the PCN WG to expect or 
> allow ECMP to be active within a PCN network, at least if is 
> a carrier network.
> 
> Regards,
> 
> Rudiger
>

---

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 22 Nov 2007 14:08:04 +0100

Hi Georgios,

true, the DSCP shouldn't be used to influence ECMP decissions.
IP adresses and may be ports. I'd have to ask my staff to get 
details. I've no problem to recommend not to base ECMP 
decisions on DSCPs.

Regards,

Rudiger

|-----Original Message-----
|From: Georgios Karagiannis [mailto:[email-masked]]
|Sent: Thursday, November 22, 2007 1:48 PM
|To: Geib, Rudiger
|Cc: [email-masked]
|Subject: RE: [PCN] Encoding PCN-markings into DSCPs - are
|thereanyinteractions with ECMP?
|
|
|Hi Ruediger
|
|An operator can however choose which type of ECMP algorithm 
|should be used in its network, or?
|Which types of ECMP algorithm is Deutsche Telecom using?
|
|We have to clarify which types of ECMP algorithms will 
|be affected when the DSCP is used for PCN purposes.
|
|Not all the ECMP algorithms are affected. I am not sure about it but 
|if the ECMP algorithms 
|that are using DSCP to select packets for load sharing might 
|not be affected
|(when DSCP is used for 
|PCN purposes) if the selection process in addition to DSCP also uses 
|the 5 tuple (for flow identification).
|
|
|Best regards,
|Georgios
|
|
|> -----Original Message-----
|> From: Geib, Ruediger [mailto:[email-masked]] 
|> Sent: donderdag 22 november 2007 9:40
|> To: [email-masked]
|> Cc: [email-masked]
|> Subject: RE: [PCN] Encoding PCN-markings into DSCPs - are 
|> there anyinteractions with ECMP?
|> 
|> Georgios,
|> 
|> if you want to convince Deutsche Telekom's backbone 
|> engineering team to turn off ECMP, you must offer them very 
|> convincing arguments. I'd suggest the PCN WG to expect or 
|> allow ECMP to be active within a PCN network, at least if is 
|> a carrier network.
|> 
|> Regards,
|> 
|> Rudiger
|> 
|> |Georgios: I am not sure about the above! An operator could at least 
|> |disallow the ECMP option.
|> |
|> |Best regards,
|> |Georgios
|> |
|> |
|> |
|> |
|> |On 11/22/2007, "[email-masked]" 
|<[email-masked]> wrote:
|> |
|> |>Hi,
|> |>Have extracted this issue as a separate thread.
|> |>The context of the discussion below is encoding PCN-markings into 
|> |>different DSCPs (ie not touching the ECN field). Question is,
|> |if you do
|> |>this are there any nasty interactions with ECMP.
|> |>Any comments?
|> |>phil
|> |>
|> |>> >
|> |>> >Major disadvantage: interactions with ECMP. ECMP algos 
|can use a 
|> |>> >packet's DSCP when deciding what interface to fwd it on. In a
|> |>PCN-domain
|> |>> >running ECMP, for a flow which has some packets 
|> PCN-marked and some 
|> |>> >unmarked. its packets will travel over more than one 
|> path. This may
|> |>well
|> |>> >lead to mis-ordering.
|> |>> >To me, this means that the S3.3 DSCP option is a 
|> non-starter in any 
|> |>> >PCN-domain that uses an ECMP algorithm that uses the DSCP.
|> |>> 
|> |>> Georgios: well I do not see this as a disadvantage. 
|> |However, what you
|> |>> mention about having an ECMP algorithm that uses DSCP is 
|relevant.
|> |>> Thus what we can do is to include a sentence in that 
|> emphasizes that
|> |>the
|> |>> ECMP situation is solved only if the ECMP algorithm does
|> |not use DSCP
|> |>> during the implementation of the equal cost multi path algorithm.
|> |>> 
|> |>> > NB ECMP algos
|> |>> >are proprietary to router vendors, ie operator has poor
|> |control over
|> |>> >them.
|> |>> 
|> |>> Georgios: I am not sure about the above! An operator 
|> could at least 
|> |>> disallow the ECN option.
|> |>> 
|> |>> 
|> |>>
|> |>
|> |>
|> |>_______________________________________________
|> |>PCN mailing list
|> |>[email-masked]
|> |>https://www1.ietf.org/mailman/listinfo/pcn
|> |
|> |
|> |_______________________________________________
|> |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: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 22 Nov 2007 14:49:20 +0100

Hi Rudiger

Thank you very much!

Best regards,
Georgios

> Sent: donderdag 22 november 2007 14:08
> thereanyinteractions with ECMP?
> 
> Hi Georgios,
> 
> should be 
> |used in its network, or?
> |We have to clarify which types of ECMP algorithms will be 
> affected when 
> |the DSCP is used for PCN purposes.
> |
> |Not all the ECMP algorithms are affected. I am not sure 
> about it but if 
> |the ECMP algorithms that are using DSCP to select packets for load 
> |sharing might not be affected (when DSCP is used for PCN 
> purposes) if 
> |the selection process in addition to DSCP also uses the 5 tuple (for 
> |flow identification).
> |
> |
> |Best regards,
> |Georgios
> |
> |
> |> Subject: RE: [PCN] Encoding PCN-markings into DSCPs - are there 
> |> anyinteractions with ECMP?
> |> 
> |> Georgios,
> |> 
> engineering team 
> |> to turn off ECMP, you must offer them very convincing 
> arguments. I'd 
> |> suggest the PCN WG to expect or allow ECMP to be active 
> within a PCN 
> |> network, at least if is a carrier network.
> |> 
> |> Regards,
> |> 
> |> Rudiger
> |>