Subject: [PCN] Comment about draft-moncaster-pcn-3-state-encoding-00

From: Fortune HUANG <[email-masked]>
Date: Thu, 24 Jul 2008 17:42:15 +0800

Hi all,

The table in section 6 seems to show that if a packet contains the DSCP
value DSCP1 or DSCP2 and Not-ECT(00) at the same time, it is a Not-PCN
packet.
      +--------+--------------+-------------+-------------+---------+
      |  DSCP  | Not-ECT (00) | ECT(0) (10) | ECT(1) (01) | CE (11) |
      +--------+--------------+-------------+-------------+---------+
      | DSCP 1 |    Not-PCN   | NM(Not-ECT) |    NM(CE)   |   ThM   |
      | DSCP 2 |    Not-PCN   |  NM(ECT(0)) |  NM(ECT(1)) |   ETM   |
      +--------+--------------+-------------+-------------+---------+
In this case, for each incoming packets, the interior node needs to identify
whether it is a PCN packet or not by two factors: the DSCP, and the ECN
bits. Because as is shown in the table, even if a packet contains the DSCP
value DSCP1 or DSCP2, it can also be a Not-PCN packet.
However, as is known to us all, one factor (i.e. the DSCP) is enough to
identify a PCN packet. And it will improve the performance before putting a
packet into the PCN queue by using only one factor to identify a PCN packet.
IMO, Not-ECT(00) doesn't need to be used. I wonder if we could put the table
in this way:
+--------+--------------+-------------+-------------+---------+
|  DSCP  | Not-ECT (00) | ECT(0) (10) | ECT(1) (01) | CE (11) |
+--------+--------------+-------------+-------------+---------+
| DSCP 1 |      -       | NM(Not-ECT) |    NM(CE)   |   ThM   |
| DSCP 2 |      -       |  NM(ECT(0)) |  NM(ECT(1)) |   ETM   |
| DSCP x |    Not-PCN   |  Not-PCN    |  Not-PCN    | Not-PCN |
+--------+--------------+-------------+-------------+---------+
NOTE: DSCPx is a DSCP codepoint other than DSCP1 and DSCP2.

Best regards,
Fortune

_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: Fortune HUANG <[email-masked]>
Date: Thu, 24 Jul 2008 19:44:39 +0800

Hi all,

In clause 4 of draft-moncaster-pcn-baseline-encoding-02, there is a
paragraph as follows:
   o  Any packet that is not PCN capable (not-PCN) but which shares the same
DiffServ codepoint as PCN capable traffic MUST have the ECN field set to 00.

From my point of view, we don't need this kind of packet which shares the
same DSCP as PCN traffic while it is not PCN traffic. Even if we want to
support this kind of packet, we can not handle it well. Obviously, this kind
of packet can not be handled like normal PCN-traffic. And it can not be
handled like ECN-traffic either, for its ECN field needs to be 00 in the PCN
domain. The reason is that if its ECN field is changed, the packet will be
mixed totally in the PCN-traffic and can't be identified by the interior
node. Furthermore, since the ECN field of this kind of packet is changed to
00 at the ingress node, and the ECN field of this kind of packet can't be
recovered at the egress node. It makes the End-to-End ECN support impossible
for this kind of packet.

If we can agree on this point, the following paragraph in clause 6.5 of
draft-ietf-pcn-architecture-04 can be removed:
   o  There may be other traffic that uses the same DSCP as PCN-traffic but
with the ECN field is 00 (Not ECT), and so not subject to PCN-marking, nor
PCN's admission control and flow termination mechanisms..  To quote
[I-D.moncaster-pcn-baseline-encoding]: "To conserve DSCPs, DiffServ
Codepoints SHOULD be chosen that are already defined for use with admission
controlled traffic, such as the Voice-Admit codepoint defined in
[voice-admit]."  Since      scheduling behaviour is coupled with the DSCP
only, therefore the same scheduling and buffer management rules are applied
to non- PCN-traffic and PCN-traffic using the same PCN-enabled DSCP. There
may be no "non-PCN-traffic", but if there is it needs to contribute to the
PCN meters.

Best Regards,
Fortune

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Fortune
HUANG
发送时间: 2008年7月24日 18:53
收件人: [email-masked]
主题: Re: [PCN] Comment about draft-moncaster-pcn-3-state-encoding-00

Hi all,

The same problem also exists in section 4 of
draft-moncaster-pcn-baseline-encoding-02.

Best Regards,
Fortune

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Fortune
HUANG
发送时间: 2008年7月24日 17:42
收件人: [email-masked]
主题: [PCN] Comment about draft-moncaster-pcn-3-state-encoding-00

Hi all,

Best regards,
Fortune