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

[<[e-mail]>]

Ingemar

Just catching up - haven't read all the thread, so sorry if this has
already been brought up.

you clear ECT to 00 at the ingress. therefore ecn [3168] doesn't work -
unless you take alternative action (Architecture draft describes the
possibilities, S3.5: [downgrade the packet to non PCN-BA, eg best
effort; tunnel the packet, so that the ECN-marking is carried
transparently across the PCN-domain.])
I don't see the fact that you carry 11 transparently makes any
difference to this. 

phil
> -----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]-
> 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:[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
> > >
> >
> >
> >
_______________________________________________
PCN mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/pcn