Re: [PCN] FW: RE: PCN encoding option
Michael Menth <menth@informatik.uni-wuerzburg.de> Fri, 22 February 2008 15:54 UTC
Return-Path: <pcn-bounces@ietf.org>
X-Original-To: ietfarch-pcn-archive@core3.amsl.com
Delivered-To: ietfarch-pcn-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9281228C1F4; Fri, 22 Feb 2008 07:54:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.582
X-Spam-Level: ***
X-Spam-Status: No, score=3.582 tagged_above=-999 required=5 tests=[AWL=-2.481, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_73=0.6, J_CHICKENPOX_91=0.6, MANGLED_TOOL=2.3, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7rbZh+IFcV7; Fri, 22 Feb 2008 07:54:43 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07E5A3A6C5F; Fri, 22 Feb 2008 07:54:43 -0800 (PST)
X-Original-To: pcn@core3.amsl.com
Delivered-To: pcn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 849E33A6C47 for <pcn@core3.amsl.com>; Fri, 22 Feb 2008 07:54:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltSvAud87cc8 for <pcn@core3.amsl.com>; Fri, 22 Feb 2008 07:54:38 -0800 (PST)
Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id C9E573A681C for <pcn@ietf.org>; Fri, 22 Feb 2008 07:54:36 -0800 (PST)
Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 82ABDA0685; Fri, 22 Feb 2008 16:54:32 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 74918A0684; Fri, 22 Feb 2008 16:54:32 +0100 (CET)
Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id D72B1A060E; Fri, 22 Feb 2008 16:54:26 +0100 (CET)
Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id m1MFsQV16468; Fri, 22 Feb 2008 16:54:26 +0100
Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 4EB90C8193; Fri, 22 Feb 2008 16:54:26 +0100 (CET)
Message-ID: <47BEEFF2.5060503@informatik.uni-wuerzburg.de>
Date: Fri, 22 Feb 2008 16:53:22 +0100
From: Michael Menth <menth@informatik.uni-wuerzburg.de>
Organization: University of Wuerzburg
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: toby.moncaster@bt.com
References: <BAB4DC0CD5148948A86BD047A85CE2A704F0364E@E03MVZ4-UKDY.domain1.systemhost.net>
In-Reply-To: <BAB4DC0CD5148948A86BD047A85CE2A704F0364E@E03MVZ4-UKDY.domain1.systemhost.net>
X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de
Cc: pcn@ietf.org, bob.briscoe@bt.com
Subject: Re: [PCN] FW: RE: PCN encoding option
X-BeenThere: pcn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: menth@informatik.uni-wuerzburg.de
List-Id: PCN WG list <pcn.ietf.org>
List-Unsubscribe: <http://www.ietf.org/mailman/listinfo/pcn>, <mailto:pcn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/pcn>
List-Post: <mailto:pcn@ietf.org>
List-Help: <mailto:pcn-request@ietf.org?subject=help>
List-Subscribe: <http://www.ietf.org/mailman/listinfo/pcn>, <mailto:pcn-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: pcn-bounces@ietf.org
Errors-To: pcn-bounces@ietf.org
Hi Toby, toby.moncaster@bt.com wrote: > Just a quick question relating to all this: What deployment scenarios do > people envisage as being sensible for the single-domain PCN solution we > are currently meant to be standardising? It strikes me that some of the > coding schemes are making assumptions about the nature of the network > topology either side of the PCN domain. > > I actually do quite like Ingemar's scheme, especially in the modified > version using a parallel DSCP which provides a really elegant way to > tunnel 11 across the PCN region. One definite con (true for many > schemes) is that you have to read both the DSCP and the ECN fields > before you can decide how to mark (as you mustn't remark TM to AM). I am > still unclear exactly how Michael envisages metering these packets? > Would you meter them with other TM marks? > All 11-marked packets would undergo the metering process with other NP, AM, and TM marked packets for admission metering, and they would also undergo the metering process with other NP, AM marked packets for termination metering. But given the fact that this raises vulnerabilities, I tend towards dropping 11-marked packets at the ingress which essentially switches off ECN capability for PCN traffic and saves a codepoint (11). This pushes Phil's idea of "blind marking": NP: 00 AM: 10 TM: 01 AM&TM: 11 The marker does not need to read the ECN bits before marking. Well, actually this is not true because only NP and AM packets should be respected for TM marking ... maybe not so helpful then as this applies only to AM-marking. Saving a codepoint might possibly be better for future use such as AffM? Regards, Michael > Toby > > >> -----Original Message----- >> From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] >> Sent: 22 February 2008 15:17 >> To: Ingemar Johansson S >> Cc: Moncaster,T,Toby,CXR9 R; karagian@cs.utwente.nl; >> Eardley,PL,Philip,CXR9 R; pcn@ietf.org; Briscoe,RJ,Bob,CXR9 R >> Subject: Re: [PCN] FW: RE: PCN encoding option >> >> Hi Ingemar, >> >> see inline. >> >> Ingemar Johansson S wrote: >> >>> Hi Michael. >>> >>> Answer inline below. >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] >>>> Sent: den 22 februari 2008 12:13 >>>> To: Ingemar Johansson S >>>> Cc: toby.moncaster@bt.com; karagian@cs.utwente.nl; >>>> philip.eardley@bt.com; pcn@ietf.org; bob.briscoe@bt.com >>>> Subject: Re: [PCN] FW: RE: PCN encoding option >>>> >>>> Hi Ingemar, >>>> >>>> Ingemar Johansson S wrote: >>>> >>>> >>>>> Hi >>>>> >>>>> See inline >>>>> >>>>> /Ingemar >>>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] >>>>>> Sent: den 22 februari 2008 10:13 >>>>>> To: Ingemar Johansson S >>>>>> Cc: toby.moncaster@bt.com; karagian@cs.utwente.nl; >>>>>> philip.eardley@bt.com; pcn@ietf.org; bob.briscoe@bt.com >>>>>> Subject: Re: [PCN] FW: RE: PCN encoding option >>>>>> >>>>>> Hi Ingemar, >>>>>> >>>>>> this solution essentially spends a DSCP to save >>>>>> >> 11-marking through >> >>>>>> the PCN domain and allow them to be PCN-marked. This is a >>>>>> >>>>>> >>>> rather high >>>> >>>> >>>>>> price, in particular because the PCN packets need to be >>>>>> >>>>>> >>>> remarked to >>>> >>>> >>>>>> 00. This has the consequence that ECN capability is lost >>>>>> >>>>>> >>>> for the rest >>>> >>>> >>>>>> of the path. >>>>>> >>>>>> >>>>>> >>>>> Not sure that I agree, yes the ECT(0), ECT(1) codepoints >>>>> >>>>> >>>> are lost and >>>> >>>> >>>>> there goes also the ECN nonce and the "inband" ECN >>>>> >>>>> >>>> capability signaling. >>>> >>>> >>>>> A router outside the PCN domain wont be able to set ECN-CE. >>>>> >>>>> >>>> However if >>>> >>>> >>>>> the ECN capability is negotiated out of band for the wireless >>>>> endpoints and the up and downlink wireless nodes, these >>>>> >>>>> >>>> will be ECN-CE >>>> >>>> >>>>> capable but without the nonce capability. >>>>> >>>>> >>>>> >>>> The difficulty is that the information for each packet >>>> whether 10 or 01 must be kept, that says RFC4774: >>>> >>>> Similarly, if a packet that *could* be using default >>>> semantics is marked with the ECN codepoint "01", then this >>>> codepoint >>>> should not be changed to "10" in the network (and a >>>> >> "10" codepoint >> >>>> should not be changed to "01"). This requirement is >>>> >> necessary to >> >>>> avoid interference with the transport protocol's use of >>>> the ECN nonce >>>> [RFC3540]. >>>> >>>> This would require a per packet signalling ... >>>> >>>> >>> Not 100% convinced here, ECN codepoints "01" and "10" can >>> >> be reset to >> >>> "00", that is my interpretation of 4.3 in RFC4774. >>> What might be seen as odd is perhaps that after PCN egress the ECN >>> pattern using this trick will only use the code points "00" or "11" >>> instead of the normal "01", "10" and "11" (if ECN capable). >>> Routers located after PCN egress won't be able to set ECN >>> >> "11" as the >> >>> flow is not anymore regarded as ECN capable (on IP level). Wireless >>> nodes such as LTE-eNB can however be instructed to set ECN >>> >> "11" during >> >>> congestion as this then controlled using out of band >>> >> signaling, this out >> >>> of band signaling is in turn controlled by policy rules >>> >> that will limit >> >>> the risk for cheating. >>> Note that this is meant for realtime traffic and a means to >>> >> do efficient >> >>> adaptation in a wireless enviroment where the transmission >>> >> capacity for >> >>> a single user changes changes dynamically due to physical >>> >> factors such >> >>> as shadowing et.c. >>> >>> >> Ok, I see. I think this is a solution not standardized by the >> IETF and >> can be done for any encoding scheme. If not, what's its >> requirement on >> the encoding? >> >> Regards, >> >> Michael >> >> >> >> >>> >>> >>> >>>>> >>>>> >>>>> >>>>> >>>>>> Therefore, I opt for one of the two versions >>>>>> 1) discard 11-marked PCN packets before entering the PCN >>>>>> >> domain OR >> >>>>>> 2) let them go through the PCN domain, take them into >>>>>> >> account for >> >>>>>> metering, but do not remark them. >>>>>> The first option loses ECN capability for PCN traffic, >>>>>> >> the second >> >>>>>> option keeps it on the subpath before entering the PCN domain. >>>>>> >>>>>> >>>>>> >>>>> Not sure I follow here. What would option 2 look like? >>>>> My interpretation: Packets with DSCP=EF enters the PCN domain, at >>>>> ingress they are remarked as DSCP=PCN unless ECN="11", in >>>>> >>>>> >>>> which case >>>> >>>> >>>>> DSCP=EF. What about ECN="01" or "01" will these also be kept as >>>>> DSCP=EF or will the ECN bits be set to "00". >>>>> Please explain. >>>>> >>>>> >>>>> >>>> EF DSCP is remarked to PCN in any case. >>>> 1) 11-marked PCN packets are dropped by the PCN ingress >>>> 2) 11 is kept as is >>>> and 01/10 marking is reset to 00 (no-precongestion). The PCN >>>> egress node resets 10/01 marked packets to 00. Therefore, the >>>> ECN capability for PCN traffic is lost >>>> 1) completely >>>> 2) for the partial downstream path starting with the PCN >>>> >> ingress node. >> >>>> It's true that PCN marking can get problems if the majority >>>> of PCN packets was CE-marked when entering the PCN domain. >>>> This kind of traffic also cheats ECN when it doesn't back >>>> off. I just want to say: even TCP senders and receivers can >>>> cheat, do we care? The question is what's more >>>> important: remaining ECN functionality for the partial path >>>> up to the PCN ingress node or safety against too many >>>> 11-marked packets. I see these options (1 and 2) and have no >>>> particular preference. >>>> >>>> Regards, >>>> >>>> Michael >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>>> Regards, >>>>>> >>>>>> Michael >>>>>> >>>>>> Ingemar Johansson S wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Hi >>>>>>> >>>>>>> Answers inline >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: toby.moncaster@bt.com [mailto:toby.moncaster@bt.com] >>>>>>>> Sent: den 21 februari 2008 15:34 >>>>>>>> To: Ingemar Johansson S; karagian@cs.utwente.nl; >>>>>>>> philip.eardley@bt.com >>>>>>>> Cc: pcn@ietf.org; bob.briscoe@bt.com; >>>>>>>> menth@informatik.uni-wuerzburg.de >>>>>>>> Subject: RE: [PCN] FW: RE: PCN encoding option >>>>>>>> >>>>>>>> Hi Ingemar, >>>>>>>> >>>>>>>> This is exactly the sort of thing Phil and I were hoping >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> to trigger >>>>>> >>>>>> >>>>>> >>>>>>>> people to write in response to our email. We are hoping to >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> settle on >>>>>> >>>>>> >>>>>> >>>>>>>> what are the real options people support for the >>>>>>>> >>>>>>>> >>>> encoding and why >>>> >>>> >>>>>>>> they support them... >>>>>>>> >>>>>>>> Just one quick observation - if we have to leave 11 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> unchanged across >>>>>> >>>>>> >>>>>> >>>>>>>> the PCN domain this will mean that such packets can't be >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> PCN marked >>>>>> >>>>>> >>>>>> >>>>>>>> and thus they should not form part of any PCN aggregate (in my >>>>>>>> opinion)... >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Realized that this is one (big) problem, thanks for >>>>>>> >>>>>>> >>>>>>> >>>>>> pointing out this >>>>>> >>>>>> >>>>>> >>>>>>> issue. >>>>>>> >>>>>>> The next alternative is then >>>>>>> PCN Meaning ECN DSCP >>>>>>> ============================= >>>>>>> PCN capable 00 PCN 1 >>>>>>> Admission Mark 01 PCN 1 >>>>>>> Termination Mark 10 PCN 1 >>>>>>> >>>>>>> PCN capable+ECN CE 00 PCN 2 >>>>>>> AM+ECN CE 01 PCN 2 >>>>>>> TM+ECN CE 10 PCN 2 >>>>>>> >>>>>>> I essence ECN-CE is mapped to PCN 2 at PCN ingress. At PCN >>>>>>> >>>>>>> >>>>>>> >>>>>> egress PCN >>>>>> >>>>>> >>>>>> >>>>>>> 2 is mapped back to the ECN bits as ECN-CE "11". >>>>>>> >>>>>>> AfM can also be included in the schema >>>>>>> >>>>>>> I know this does cost an extra DSCP codepoint and it completely >>>>>>> disregards the leakage issue, also it possible that this >>>>>>> >>>>>>> >>>>>>> >>>>>> alternative >>>>>> >>>>>> >>>>>> >>>>>>> or something similar is given in the PCN encoding draft >>>>>>> >>>>>>> >>>> but I don't >>>> >>>> >>>>>>> think so as this alternative does not preserve the end >>>>>>> >> to end ECN >> >>>>>>> semantics to 100%, rather it assumes that negotiation of >>>>>>> >>>>>>> >>>> the use of >>>> >>>> >>>>>>> ECN is done out of band at session setup. >>>>>>> >>>>>>> /Ingemar >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Toby >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Ingemar Johansson S >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> [mailto:ingemar.s.johansson@ericsson.com] >>>>>> >>>>>> >>>>>> >>>>>>>>> Sent: 21 February 2008 13:47 >>>>>>>>> To: Georgios Karagiannis; Eardley,PL,Philip,CXR9 R >>>>>>>>> Cc: pcn@ietf.org; Briscoe,RJ,Bob,CXR9 R; >>>>>>>>> menth@informatik.uni-wuerzburg.de; Moncaster,T,Toby,CXR9 R >>>>>>>>> Subject: RE: [PCN] FW: RE: PCN encoding option >>>>>>>>> >>>>>>>>> Hi >>>>>>>>> >>>>>>>>> Putting the issues with "leakage" aside (I cannot tell >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> how serious >>>>>> >>>>>> >>>>>> >>>>>>>>> this problem really is). >>>>>>>>> >>>>>>>>> I would prefer to sacrifice the end to end ECN >>>>>>>>> >> semantics for the >> >>>>>>>>> ECT(0) and ECT(1) codepoints instead of the ECN-CE >>>>>>>>> >>>>>>>>> >>>> codepoint. The >>>> >>>> >>>>>>>>> reason is simply that from a realtime communication >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> scenario with out >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> of band signaling it is always possible to negotiate the >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> use of ECN CE >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> mark in wireless nodes by means of eg. SIP signaling. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> Also, atleast >>>>>> >>>>>> >>>>>> >>>>>>>>> for RTP/UDP I see little use for ECN nonce like it is done >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> with TCP as >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> this is more or less an anti-cheat feature. >>>>>>>>> >>>>>>>>> >>>>>>>>> One would then end up with a PCN encoding schema like >>>>>>>>> >> (I beleve >> >>>>>>>>> option 5 in figure 1 in the PCN encoding draft) is >>>>>>>>> >> the closest. >> >>>>>>>>> PCN Meaning ECN DSCP >>>>>>>>> ============================= >>>>>>>>> PCN capable 00 PCN 1 >>>>>>>>> Admission Mark 01 PCN 1 >>>>>>>>> Termination Mark 10 PCN 1 >>>>>>>>> >>>>>>>>> At PCN ingress the ECT(0) and ECT(1) codepoints should be >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> set to "00", >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> likewise at PCN egress. ECN CE is however left untouched. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> This has the >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> effect that routers will be able to set ECN-CE on packets >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> before they >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> enter the first PCN domain, after exit from the PCN >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> domain routers >>>>>> >>>>>> >>>>>> >>>>>>>>> are not anymore allowed to set ECN-CE (RFC4774 section 4.3). >>>>>>>>> Wireless nodes >>>>>>>>> such as LTE-eNB (Long Term Evolution-Enhanced Node B) can >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> however set >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> ECN CE as this is can be managed by out of band signaling. >>>>>>>>> >>>>>>>>> Besides this I would prefer a solution that maintains >>>>>>>>> >>>>>>>>> >>>> end to end >>>> >>>> >>>>>>>>> semantics regardless of DSCP value. If one consider DCCP we >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> don't know >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> today if it will be a best effort traffic alternatiive or >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> if there >>>>>> >>>>>> >>>>>> >>>>>>>>> is a benefit with it even with QoS and DCCP can use ECN nonce. >>>>>>>>> >>>>>>>>> /Ingemar >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >>>>>>>>>> Sent: den 21 februari 2008 11:07 >>>>>>>>>> To: philip.eardley@bt.com; Ingemar Johansson S >>>>>>>>>> Cc: pcn@ietf.org; bob.briscoe@bt.com; >>>>>>>>>> menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com >>>>>>>>>> Subject: RE: [PCN] FW: RE: PCN encoding option >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hi Phil, Hi all >>>>>>>>>> >>>>>>>>>> In order to make a selection of one single (or two) >>>>>>>>>> >> options, I >> >>>>>>>>>> think that the PCN WG should get the possibility to >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> study all the >>>>>> >>>>>> >>>>>> >>>>>>>>>> possible and PCN relevant encoding options. >>>>>>>>>> >>>>>>>>>> In my opinion the goal of the encoding draft is to >>>>>>>>>> >>>>>>>>>> >>>> provide this >>>> >>>> >>>>>>>>>> information to the PCN-WG. >>>>>>>>>> Based on this information the PCN WG can discuss and >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> decide which >>>>>> >>>>>> >>>>>> >>>>>>>>>> of the options should be used. >>>>>>>>>> >>>>>>>>>> The below text is copied from the current version of the >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> encoding >>>>>> >>>>>> >>>>>> >>>>>>>>>> draft! >>>>>>>>>> Four options are described! >>>>>>>>>> Please note that the encoding draft should list all relevant >>>>>>>>>> options with advantages and disadvantages. >>>>>>>>>> >>>>>>>>>> Phil and Ingemar, if you can add advantages, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> disadvantages to the >>>>>> >>>>>> >>>>>> >>>>>>>>>> ones already mentioned below in Section 3.2.1 and >>>>>>>>>> >> 3.2.2 of the >> >>>>>>>>>> encoding draft, please do. >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Georgios >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 3.2. Encoding Using DSCP Field >>>>>>>>>> >>>>>>>>>> In this type of encoding and transport method the >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> congestion and >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>> precongestion information is encoded into the 6 DSCP >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> bits that are >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> transported in the IP header of the data packets. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> Four possible >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>> alternatives can be distinguished, as can be seen in >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Figure 3, with >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> details provided by >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> draft-westberg-pcn-load-control-02.txt [4]. >>>>>> >>>>>> >>>>>> >>>>>>>>>> Option 7 needs 2 additional DSCP values, Options 8 and 9 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> need three >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> additional DSCP values and Option 10 needs four >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> additional DSCP >>>>>> >>>>>> >>>>>> >>>>>>>>>> values. Note that all additional and experimental DSCP >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> values are >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> representing and are associated with the same PHB. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> The 1st, 2nd, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>> 3rd, and 4th DSCP values are representing DSCP >>>>>>>>>> >>>>>>>>>> >>>> values that are >>>> >>>> >>>>>>>>>> assigned by IANA as DSCP experimental values, see RFC >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> 2211 [9]. >>>>>> >>>>>> >>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >> -------------------------------------------------------------- >> >>>>>>>>>> --------- >>>>>>>>>> | DSCP Bits || Original |Add DSCP 1 |Add DSCP 2 |Add >>>>>>>>>> >>>>>>>>>> >>>> DSCP 3 Add >>>> >>>> >>>>>>>>>> |DSCP 4 >>>>>>>>>> || >>>>>>>>>> >>>>>>>>>> >> ===========++==========+===========+===========+===========+== >> >>>>>>>>>> =========| >>>>>>>>>> | Option 6 || Not-PCN | PCN | AM/TM | >>>>>>>>>> >> NA | >> >>>>>>>>>> NA | >>>>>>>>>> >>>>>>>>>> >> |-----------++----------+-----------+-----------+-----------+- >> >>>>>>>>>> ----------| >>>>>>>>>> | Option 7 || Not-PCN | PCN | AM/TM | >>>>>>>>>> >> AfM | >> >>>>>>>>>> NA | >>>>>>>>>> >>>>>>>>>> >> |-----------++----------+-----------+-----------+-----------+- >> >>>>>>>>>> ----------| >>>>>>>>>> | Option 8 || Not-PCN | PCN | AM | >>>>>>>>>> >> TM | >> >>>>>>>>>> NA | >>>>>>>>>> >>>>>>>>>> >> |-----------++----------+-----------+-----------+-----------+- >> >>>>>>>>>> ----------| >>>>>>>>>> | Option 9 || Not-PCN | PCN | AM | >>>>>>>>>> >> TM | >> >>>>>>>>>> AfM | >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >> -------------------------------------------------------------- >> >>>>>>>>>> --------- >>>>>>>>>> >>>>>>>>>> Notes: Not-PCN means the packet is not PCN capable. >>>>>>>>>> >>>>>>>>>> Figure 2: Encoding of PCN Information Using >>>>>>>>>> >>>>>>>>>> >>>> DSCP Field >>>> >>>> >>>>>>>>>> 3.2.1. Benefits of Using DSCP Field >>>>>>>>>> >>>>>>>>>> The main benefit of using the DSCP field is that >>>>>>>>>> >> it is not >> >>>>>>>>>> affecting >>>>>>>>>> the end-to-end ECN semantics and therefore the issues >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> and concerns >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> raised in RFC 4774 [22] are not applicable for this >>>>>>>>>> >>>>>>>>>> >>>> encoding >>>> >>>> >>>>>>>>>> scheme. >>>>>>>>>> Another benefit is related to the fact that all 4 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> DSCP encoding >>>>>> >>>>>> >>>>>> >>>>>>>>>> options depicted in Figure 2 can support the PCN >>>>>>>>>> >> capable not >> >>>>>>>>>> congested (PCN) indication, the admission control >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> (AM) and flow >>>>>> >>>>>> >>>>>> >>>>>>>>>> termination (TM) encoding states. In addition Option 8 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> and 10 can >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> support the ECMP solution. >>>>>>>>>> >>>>>>>>>> 3.2.2. Drawbacks of Using DSCP Field >>>>>>>>>> >>>>>>>>>> This type of encoding needs to use per PHB, in >>>>>>>>>> >>>>>>>>>> >>>> addition to the >>>> >>>> >>>>>>>>>> original DSCP and depending on the encoding option used, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> one, two, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> three, or four DSCP values, respectively. These >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> additional DSCP >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>> values can be taken from the DSCP values that are not >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> defined by >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>> standards action, see RFC 2211 [9]. Note that all the >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> additional >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>> DSCP values are representing and are associated with one >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> PHB. The >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> value of this DSCP/PHB can either follow a standards >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> action or >>>>>> >>>>>> >>>>>> >>>>>>>>>> use a >>>>>>>>>> value that is applied for experimental or local >>>>>>>>>> >> use. It is >> >>>>>>>>>> important >>>>>>>>>> to note that the number of the DSCP values used >>>>>>>>>> >> for local or >> >>>>>>>>>> experimental use is restricted and therefore the >>>>>>>>>> >> number of >> >>>>>>>>>> different >>>>>>>>>> PHBs supported in the PCN domain will also be restricted. >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Georgios >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Behalf Of >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> philip.eardley@bt.com >>>>>>>>>>> Sent: donderdag 21 februari 2008 10:24 >>>>>>>>>>> To: ingemar.s.johansson@ericsson.com; >>>>>>>>>>> menth@informatik.uni-wuerzburg.de; toby.moncaster@bt.com >>>>>>>>>>> Cc: pcn@ietf.org; bob.briscoe@bt.com >>>>>>>>>>> Subject: Re: [PCN] FW: RE: PCN encoding option >>>>>>>>>>> >>>>>>>>>>> Ingemar >>>>>>>>>>> >>>>>>>>>>> Re >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> consider the end to end ECN usecases >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> I believe that the emails below about Toby's encoding >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>> proposal do >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>> indeed already consider ECN. Would appreciate it if you >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>> could add >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>> further text to it to better capture the (pros and) cons. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> more DSCP codepoints >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> I think you may be proposing an encoding that uses all dscp >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> codepoints >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> (as has Georgios). That's fine - but a "1 pager" >>>>>>>>>>> setting out this option with its pros and cons (ie >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> similar to what >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> toby has done below) is needed I think! At the moment we >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> have lots of >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> options on the table - in order to reach a decision, I >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> think we really >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> need very few options but with their pros and cons better >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> laid out. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> I haven't managed to get to your draft yet, sorry (next week >>>>>>>>>>> hopefully) >>>>>>>>>>> - >>>>>>>>>>> Thanks >>>>>>>>>>> Phil >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Ingemar Johansson S >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> [mailto:ingemar.s.johansson@ericsson.com] >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> Sent: 21 February 2008 06:43 >>>>>>>>>>>> To: Eardley,PL,Philip,CXR9 R; >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> menth@informatik.uni-wuerzburg.de; >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>> Moncaster,T,Toby,CXR9 R >>>>>>>>>>>> Cc: pcn@ietf.org; Briscoe,RJ,Bob,CXR9 R >>>>>>>>>>>> Subject: RE: [PCN] FW: RE: PCN encoding option >>>>>>>>>>>> >>>>>>>>>>>> Hi >>>>>>>>>>>> >>>>>>>>>>>> In this discussion it may be well worth the effort to >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> consider the end >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> to end ECN usecases that we foresee when considering >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> various PCN >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> encoding options. >>>>>>>>>>>> Please have a look at >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >> http://tools.ietf.org/wg/pcn/draft-sarker-pcn-ecn-pcn-usecases-00.txt >> >>>> >>>> >>>>>> >>>>>> >>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>> for a discussion of the use cases and a motivation to why >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> end to end >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> ECN >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> should be maintained even across PCN nodes even for non >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> DF traffic. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> That said I realize that there is some cost associated to >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> the use of >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> DSCP codepoints, this cost must however be weighted against >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> the risk >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> that other functionality like end to end ECN semantics is >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> probably >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> broken if a PCN encoding option "fiddles" with the ECN >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> bits. It is >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> easy >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> to see that if one wish to maintain support for end to >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> end ECN (not >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> only >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> in DF class) it simply costs more DSCP codepoints. >>>>>>>>>>>> I am not explicitly saying don't do this or that but I wish >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> to avoid a >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> situation where one technique has to be avoided in favor of >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> the other >>>>>>>>>>> as >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> it may in the end prevent deployment of both. If one can >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> yank the two >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> together so much the better even though the cost e.g in >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> DSCP code >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> points >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> is regarded as higher. >>>>>>>>>>>> >>>>>>>>>>>> Regards >>>>>>>>>>>> Ingemar >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> On Behalf >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> Of philip.eardley@bt.com >>>>>>>>>>>>> Sent: den 20 februari 2008 17:44 >>>>>>>>>>>>> To: menth@informatik.uni-wuerzburg.de; >>>>>>>>>>>>> >> toby.moncaster@bt.com >> >>>>>>>>>>>>> Cc: pcn@ietf.org; bob.briscoe@bt.com >>>>>>>>>>>>> Subject: Re: [PCN] FW: RE: PCN encoding option >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks Michael >>>>>>>>>>>>> >>>>>>>>>>>>> I agree with you that spending one DSCP value is quite >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> expensive >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> (not two, as one is spent anyway). I think the only way >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> of really >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> assessing this properly is for an alternative proposal >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> (with pros >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> and cons) that requires only one DSCP. >>>>>>>>>>>>> Then we can see where the consensus for the best >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>> (/least bad) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>> encoding lies. Personally I have no axe to grind for >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> or against >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> either - I'm not yet convinced that the proposal below is >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> definitely >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> the way to go, until compared it in detail with other >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> proposals. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> So I think it would be really useful to have a "1 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>> pager" for >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>> alternative >>>>>>>>>>>>> proposal(s) before the ietf, as I think this would make >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> Philadelphia >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> discussions more productive. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> You're correct about one of the motivations >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> (advantages) for this >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> proposal (although I don't think the issues are exactly >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> the same for >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> 11 leakage as 01/10 leakage). >>>>>>>>>>>>> >>>>>>>>>>>>> Consider the case where 11 leaks out of the PCN >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> domain. If the >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> endpoints are ECN capable, then the ECN source slows >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> down (seems >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> reasonable). If they're not capable, then the impact >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> outside the >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> domain isn't any different to what would happen without >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> PCN-domain. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> Consider the case where ECN-11 leaks into the PCN domain. >>>>>>>>>>>>> Then this will lead to either flow admission or >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> termination in the >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> PCN-domain. These are both safe, in that the reaction is >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> (I believe) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> at least as severe as would happen in an all ECN world. >>>>>>>>>>>>> You mention that this might not terminate the ECN-11 flow >>>>>>>>>>>>> specifically (some other flow might get >>>>>>>>>>>>> >> terminated instead). >> >>>>>>>>>>>>> I think this is true, though it also implies that [1] >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> end-to-end ECN >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> & PCN on the same flow really is useful, [2] the >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>> mechanism (eg >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>> tunnelling) to carry ECN-marking transparently across the >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> PCN-domain >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> has also failed, [3] the flows which are terminated >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> aren't other >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> ECN-11 flows that are also getting in due to the same >>>>>>>>>>>>> misconfiguration. >>>>>>>>>>>>> >>>>>>>>>>>>> Best wishes >>>>>>>>>>>>> Phil >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: Michael Menth >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>> [mailto:menth@informatik.uni-wuerzburg.de] >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>>>> Sent: 20 February 2008 10:50 >>>>>>>>>>>>>> To: Moncaster,T,Toby,CXR9 R >>>>>>>>>>>>>> Cc: pcn@ietf.org; Eardley,PL,Philip,CXR9 R; >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> khchan@nortel.com; >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>> babiarz@nortel.com; sob@harvard.edu; >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> steven.blake@ericsson.com; >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>> karagian@cs.utwente.nl; Briscoe,RJ,Bob,CXR9 R >>>>>>>>>>>>>> Subject: Re: FW: RE: PCN encoding option >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Toby, >>>>>>>>>>>>>> >>>>>>>>>>>>>> as I understand the proposal, the motivation is to >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> avoid 01/10 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>> codepoints as it is not good if they leak out of the >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>> network since >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> 01/10 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> is interpreted as ECN-capable ECT(0/1) by ECN nodes. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> However, there is >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> the same problem with 11 marking, i.e. 11-packets >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>> may not be >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>> dropped >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> by >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> ECN nodes outside the PCN domain although endpoints >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> are not ECN >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> capable. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Even if 11-packets trigger flow termination, it is not >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> guaranteed that >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> exactly the marked flow going over an overloaded >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>> ECN node is >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>> terminated. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Just want to say that this solution wants to solve a >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>> problem that >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> exists >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> only in case of misconfiguration (leaking packets), but >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> does not fully >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> achieve that objective. Therefore, I feel that >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> spending two DSCP >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> values >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> is quite expensive. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Michael >>>>>>>>>>>>>> >>>>>>>>>>>>>> toby.moncaster@bt.com wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> All, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Phil and I have just been discussing the encoding draft >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> and feel we >>>>>>>>>>>>> may >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> have lit upon a neat solution that seems to have >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> lots of pros >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> and >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> few >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> cons... In order to get a better feeling for this >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> proposal I will go >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> through the simplified version without Affected >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> marking first: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> PCN Meaning ECN DSCP >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> PCN capable 00 PCN 1 >>>>>>>>>>>>>>> Admission Mark 11 PCN 1 >>>>>>>>>>>>>>> Termination Mark 11/00 PCN 2 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> PCN 1 and PCN 2 are 2 different codepoints with >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>> the same PCN >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> behaviour >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> aggregate. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Pros: >>>>>>>>>>>>>>> o Termination marking and admission marking are >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> independent, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> eg >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>>> termination marking can be done after a packet has been >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>> admission >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>>> marked. Therefore a router can write AM or TM without >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> having to read >>>>>>>>>>>>> the >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> packet's PCN marking first, which is easier to >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>> implement. (Note: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>>> Over-writing a TM with AM is not allowed for >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> 3SM & CL, see >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>>> draft-charny-pcn-comparison.) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> o This scheme avoids giving semantics to ECT(0) and >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> ECT(1). This is >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> safest option if packets leak outside the PCN >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>> region, due to >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> some >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> fort >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> of misconfiguration of the PCN-boundary-nodes (relevant >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> for a single >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> domain deployment of PCN). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> o It leaves open the possibility of using ECT(0) and >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> ECT(1) in some >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> mysterious way in a future end-to-end PCN deployment >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> o For a router to classify a packet as PCN, it >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>> simply reads its >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> > > >>>>>>>>>>>>> DSCP. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> This is probably easier than checking both its >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> DSCP & ECN >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>> fields. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>>> o Incremental deployment steps are possible [1] >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>> could deploy SM >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>>> initially and later AM/TM. Just add the second >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> DSCP. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> If a router isn't upgraded at the same time nothing >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>> too horrific >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>>> happens. >>>>>>>>>>>>>>> [2] could just deploy admission control & add >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>> termination later, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> just by >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> adding a new DSCP; there is no need to change the >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> encoding and check >>>>>>>>>>>>> for >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> backwards compatibility? Vice-versa is also ok? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Cons: >>>>>>>>>>>>>>> o It needs an extra DSCP, per PCN behaviour aggregate. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>> (Although >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>>> possibly it's OK to use the same DSCP for TM for >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> all PCN BAs?) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> o If a packet (in a PCN flow) arrives at the >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> egress with >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>> its ECN = >>>>>>>>>>>>> 11 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> and it really is required to preserve this info >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> across the >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>> PCN-domain, >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> then some complexity is needed at the PCN-boundary-nodes >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> (tunnelling) >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> o If the PCN-domain is operating multipath routing >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> (ECMP) that uses >>>>>>>>>>>>> the >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> DSCP to select routes, then there may be mis-ordering >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>> of packets >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> within >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> a flow. This may be OK as (1) no-one has yet said >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> they know of >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> an >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> ECMP >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> algorithm that in practie uses the DSCP; (2) a risk of >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> mis-ordering >>>>>>>>>>>>> when >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> there is termination marking may be acceptable >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> If Affected marking is needed then the scheme can be >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>> modified as >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>>> follows: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> PCN Meaning ECN DSCP >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> PCN capable 00 PCN 1 >>>>>>>>>>>>>>> Admission Mark 11 PCN 1 >>>>>>>>>>>>>>> Termination Mark 11 PCN 2 >>>>>>>>>>>>>>> Affected Mark 00 PCN 2 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The pros for this scheme are broadly similar to >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> the above. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>> However >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> there >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> is a new con which may or may not matter: If a packet is >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>> affected >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> marked >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> and a later node is doing admission marking then it will >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> reset the >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> affected mark to a termination mark. Work would >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> be needed >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>> to see if >>>>>>>>>>>>> this >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> skews the results and causes significant >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>> over-termination or >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> not. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>>> Please could people look through this scheme and >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>> highlight any >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>>> additional concerns that they may have (and extra >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>> benefits too). >>>>>>>>>>> I >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> would >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> like to get as many opinions as possible. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> What I want to avoid is people just emailing back with >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> "why not try >>>>>>>>>>>>> this >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> scheme instead". Currently we seem to have a plethora of >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>> possible >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>>> schemes on the table and people need to start putting >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>> down much >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> clearer >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> pros and cons for the schemes they support... >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> So it could >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>> be good to >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> have a similar "one page" email about a specific >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>> scheme that >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> only >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> uses >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> one DSCP for PCN, but uses the 01/10 codepoints instead. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Toby >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >> ____________________________________________________________________ >> >>>> >>>> >>>>>> >>>>>> >>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>>>>> Toby Moncaster, <toby.moncaster@bt.com> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> Networks Research >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>> Centre, BT >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>> 1473 648734 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> 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:menth@informatik.uni-wuerzburg.de >>>>>>>>>>>>>> http://www3.informatik.uni-wuerzburg.de/research/ngn >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> PCN mailing list >>>>>>>>>>>>> PCN@ietf.org >>>>>>>>>>>>> http://www.ietf.org/mailman/listinfo/pcn >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> PCN mailing list >>>>>>>>>>> PCN@ietf.org >>>>>>>>>>> http://www.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:menth@informatik.uni-wuerzburg.de >>>>>> http://www3.informatik.uni-wuerzburg.de/research/ngn >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> -- >>>> 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:menth@informatik.uni-wuerzburg.de >>>> http://www3.informatik.uni-wuerzburg.de/research/ngn >>>> >>>> >>>> >>>> >> -- >> 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:menth@informatik.uni-wuerzburg.de >> http://www3.informatik.uni-wuerzburg.de/research/ngn >> >> >> -- 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:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org http://www.ietf.org/mailman/listinfo/pcn
- [PCN] FW: RE: PCN encoding option toby.moncaster
- Re: [PCN] FW: RE: PCN encoding option Michael Menth
- Re: [PCN] FW: RE: PCN encoding option philip.eardley
- Re: [PCN] FW: RE: PCN encoding option philip.eardley
- Re: [PCN] FW: RE: PCN encoding option toby.moncaster
- Re: [PCN] FW: RE: PCN encoding option Michael Menth
- Re: [PCN] FW: RE: PCN encoding option Michael Menth
- Re: [PCN] FW: RE: PCN encoding option Ingemar Johansson S
- Re: [PCN] FW: RE: PCN encoding option philip.eardley
- Re: [PCN] FW: RE: PCN encoding option Michael Menth
- Re: [PCN] FW: RE: PCN encoding option philip.eardley
- Re: [PCN] FW: RE: PCN encoding option Michael Menth
- Re: [PCN] FW: RE: PCN encoding option Georgios Karagiannis
- Re: [PCN] FW: RE: PCN encoding option toby.moncaster
- Re: [PCN] FW: RE: PCN encoding option philip.eardley
- Re: [PCN] FW: RE: PCN encoding option toby.moncaster
- Re: [PCN] FW: RE: PCN encoding option Georgios Karagiannis
- Re: [PCN] FW: RE: PCN encoding option Ingemar Johansson S
- Re: [PCN] FW: RE: PCN encoding option philip.eardley
- [PCN] Routers and ECMP (part of FW: RE: PCN encod… Geib, Ruediger
- Re: [PCN] FW: RE: PCN encoding option Georgios Karagiannis
- Re: [PCN] FW: RE: PCN encoding option toby.moncaster
- Re: [PCN] FW: RE: PCN encoding option toby.moncaster
- Re: [PCN] FW: RE: PCN encoding option philip.eardley
- Re: [PCN] FW: RE: PCN encoding option Georgios Karagiannis
- Re: [PCN] FW: RE: PCN encoding option Geib, Ruediger
- Re: [PCN] FW: RE: PCN encoding option Lars Eggert
- Re: [PCN] FW: RE: PCN encoding option Michael Menth
- Re: [PCN] FW: RE: PCN encoding option Geib, Ruediger
- Re: [PCN] FW: RE: PCN encoding option Ingemar Johansson S
- Re: [PCN] FW: RE: PCN encoding option Michael Menth
- Re: [PCN] FW: RE: PCN encoding option Geib, Ruediger
- Re: [PCN] FW: RE: PCN encoding option Ingemar Johansson S
- Re: [PCN] FW: RE: PCN encoding option toby.moncaster
- Re: [PCN] FW: RE: PCN encoding option Geib, Ruediger
- Re: [PCN] FW: RE: PCN encoding option Michael Menth
- Re: [PCN] FW: RE: PCN encoding option Michael Menth
- Re: [PCN] FW: RE: PCN encoding option Ingemar Johansson S
- Re: [PCN] FW: RE: PCN encoding option Michael Menth
- Re: [PCN] FW: RE: PCN encoding option philip.eardley
- Re: [PCN] FW: RE: PCN encoding option Michael Menth
- Re: [PCN] FW: RE: PCN encoding option philip.eardley
- [PCN] Resetting ECT to non-ECT Michael Menth
- Re: [PCN] FW: RE: PCN encoding option Jozef Babiarz
- Re: [PCN] FW: RE: PCN encoding option Steven Blake
- Re: [PCN] FW: RE: PCN encoding option Geib, Ruediger
- Re: [PCN] FW: RE: PCN encoding option toby.moncaster
- Re: [PCN] FW: RE: PCN encoding option Geib, Ruediger