Re: [PCN] FW: RE: PCN encoding option
Michael Menth <menth@informatik.uni-wuerzburg.de> Fri, 22 February 2008 15:18 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 8BF1028C33E; Fri, 22 Feb 2008 07:18:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.433
X-Spam-Level: ***
X-Spam-Status: No, score=3.433 tagged_above=-999 required=5 tests=[AWL=-2.630, 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 ysPdyP8rsayG; Fri, 22 Feb 2008 07:18:44 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97A883A6817; Fri, 22 Feb 2008 07:18:44 -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 B10EF28C2A4 for <pcn@core3.amsl.com>; Fri, 22 Feb 2008 07:18:42 -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 765z1lSH67Gb for <pcn@core3.amsl.com>; Fri, 22 Feb 2008 07:18:39 -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 D8FEB3A67D7 for <pcn@ietf.org>; Fri, 22 Feb 2008 07:18:38 -0800 (PST)
Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 605EBA0664; Fri, 22 Feb 2008 16:18:34 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 51F4BA064D; Fri, 22 Feb 2008 16:18:34 +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 AA6F0A067A; Fri, 22 Feb 2008 16:18:28 +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 m1MFISV16011; Fri, 22 Feb 2008 16:18:28 +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 5D168C8785; Fri, 22 Feb 2008 16:18:28 +0100 (CET)
Message-ID: <47BEE784.6070902@informatik.uni-wuerzburg.de>
Date: Fri, 22 Feb 2008 16:17:24 +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: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
References: <026F8EEDAD2C4342A993203088C1FC050260E1CC@esealmw109.eemea.ericsson.se> <BAB4DC0CD5148948A86BD047A85CE2A704EB0EDB@E03MVZ4-UKDY.domain1.systemhost.net> <026F8EEDAD2C4342A993203088C1FC050260E1CF@esealmw109.eemea.ericsson.se> <47BE9231.2010602@informatik.uni-wuerzburg.de> <026F8EEDAD2C4342A993203088C1FC050260E1D1@esealmw109.eemea.ericsson.se> <47BEAE2D.1090305@informatik.uni-wuerzburg.de> <026F8EEDAD2C4342A993203088C1FC050260E1D8@esealmw109.eemea.ericsson.se>
In-Reply-To: <026F8EEDAD2C4342A993203088C1FC050260E1D8@esealmw109.eemea.ericsson.se>
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 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 _______________________________________________ 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