Re: [PCN] FW: RE: PCN encoding option

["Ingemar Johansson S" <[e-mail]>]

Hi

See inline

/Ingemar

> -----Original Message-----
> From: Michael Menth [mailto:[e-mail]] 
> Sent: den 22 februari 2008 10:13
> To: Ingemar Johansson S
> Cc: [e-mail]; [e-mail]; 
> [e-mail]; [e-mail]; [e-mail]
> 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. 
 
> 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.



> 
> Regards,
> 
>     Michael
> 
> Ingemar Johansson S wrote:
> > Hi
> >
> > Answers inline
> >
> >   
> >> -----Original Message-----
> >> From: [e-mail] [mailto:[e-mail]]
> >> Sent: den 21 februari 2008 15:34
> >> To: Ingemar Johansson S; [e-mail]; 
> >> [e-mail]
> >> Cc: [e-mail]; [e-mail]; 
> >> [e-mail]
> >> 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:[e-mail]]
> >>> Sent: 21 February 2008 13:47
> >>> To: Georgios Karagiannis; Eardley,PL,Philip,CXR9 R
> >>> Cc: [e-mail]; Briscoe,RJ,Bob,CXR9 R; 
> >>> [e-mail]; 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:[e-mail]]
> >>>> Sent: den 21 februari 2008 11:07
> >>>> To: [e-mail]; Ingemar Johansson S
> >>>> Cc: [e-mail]; [e-mail]; 
> >>>> [e-mail]; [e-mail]
> >>>> 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: [e-mail] [mailto:[e-mail]] On
> >>>>>           
> >>>> Behalf Of
> >>>>         
> >>>>> [e-mail]
> >>>>> Sent: donderdag 21 februari 2008 10:24
> >>>>> To: [e-mail]; 
> >>>>> [e-mail]; [e-mail]
> >>>>> Cc: [e-mail]; [e-mail]
> >>>>> 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:[e-mail]]
> >>>>         
> >>>>>> Sent: 21 February 2008 06:43
> >>>>>> To: Eardley,PL,Philip,CXR9 R;
> >>>>>>             
> >> [e-mail];
> >>     
> >>>>>> Moncaster,T,Toby,CXR9 R
> >>>>>> Cc: [e-mail]; 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: [e-mail] [mailto:[e-mail]]
> >>>>>>>               
> >>>>> On Behalf
> >>>>>           
> >>>>>>> Of [e-mail]
> >>>>>>> Sent: den 20 februari 2008 17:44
> >>>>>>> To: [e-mail]; [e-mail]
> >>>>>>> Cc: [e-mail]; [e-mail]
> >>>>>>> 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:[e-mail]]
> >>>       
> >>>>>>>> Sent: 20 February 2008 10:50
> >>>>>>>> To: Moncaster,T,Toby,CXR9 R
> >>>>>>>> Cc: [e-mail]; Eardley,PL,Philip,CXR9 R;
> >>>>>>>>                 
> >>>> [e-mail];
> >>>>         
> >>>>>>>> [e-mail]; [e-mail];
> >>>>>>>>                 
> >>>> [e-mail];
> >>>>         
> >>>>>>>> [e-mail]; 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
> >>>>>>>>
> >>>>>>>> [e-mail] 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, <[e-mail]>
> >>>>>>>>>                   
> >> 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: [phone], fax: [phone] 
> >>>>>>>> mailto:[e-mail]
> >>>>>>>> http://www3.informatik.uni-wuerzburg.de/research/ngn
> >>>>>>>>                 
> >>>>>>> _______________________________________________
> >>>>>>> PCN mailing list
> >>>>>>> [e-mail]
> >>>>>>> http://www.ietf.org/mailman/listinfo/pcn
> >>>>>>>
> >>>>>>>               
> >>>>> _______________________________________________
> >>>>> PCN mailing list
> >>>>> [e-mail]
> >>>>> 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: [phone], fax: [phone] 
> mailto:[e-mail]
> http://www3.informatik.uni-wuerzburg.de/research/ngn
> 
> 
_______________________________________________
PCN mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/pcn