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

[<[e-mail]>]

3 replies below to snippets from this thread
phil

> 
> resetting 01- and 10-marked packets to 00-marking does not conflict
with
> RFC4774, only interchanging them is bad:

don't agree. Swapping 01 & 10 breaks the ecn nonce. But setting ect [10
or 01] to 00 turns off ECN 3168. since 3168 is a STD, this is a problem.

> 
>    A requirement for compatibility with end-nodes using default ECN is
>    that if a packet that *could* be using default semantics is marked
>    with the ECN codepoint "00", this marking must not be changed to
>    "01", "10", or "11" in the network.  This prevents the packet from
>    being represented incorrectly to a default-ECN router downstream as
>    ECN-Capable.  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].
> 
> Regards,
> 
> 	Michael
> 

----
Ingemar said:
> 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.
think the talk about future uses of ECN by wireless users is a bit
speculative. Worrying about things that are ietf stds already is hard
enough!

-----
Elsewhere Ingemar also said:
> 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
this could be directly compared with toby's scheme, in that they both
use ECN & 2 DSCPs.

So I copied in the pros and cons that toby claims for his scheme, &
added some remarks below to compare with your idea
> 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.)
your scheme doesn't have this pro 
> 
> 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).
see issue above about loss of 3168 semantics.
> 
> 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?
This pro is lost
> 
> 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)
you're trying to avoid this con, which is a noble aim & would be nice if
succeed, although I don't think you've managed it
> 
> 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
point (2) doesn't hold for your scheme 
_______________________________________________
PCN mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/pcn