[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PCN] FW: New Version Notification fordraft-ietf-pcn-baseline-encoding-05
Few minor comments:
Table 1 has
>EXP(01)*
>Valid* [in IN EXP(01) OUT PM(11) box]
> * This SHOULD cause an alarm to be raised at a higher layer. The
packet MUST be treated as if it carried the NM codepoint.
I think your comment ["*This SHOULD.."] really only applies to the "EXP(01)*" - ie if the codepoint in is EXP(01) then raise an alarm as this shouldn't happen.
Both the "Valid" boxes in this row could have a comment:
** these transitions MAY be allowed be some future experimental extensions to the baseline encoding. However a PCN-node that hasn't be upgraded (ie is still doing baseline) mustn't block this so it MUST treat this transition as valid; it MAY also raise an alarm.
[Not sure " MAY also raise an alarm" is needed, since alarm already raised since EXP(01) is the codepoint in]
> alarm to be raised at a higher layer
is 'higher layer' right? how about "management alarm"?
> A PCN-egress-node SHOULD set the not-PCN (00) codepoint on all
packets it forwards out of the PCN-domain. The only exception to
this is if the PCN-egress-node is certain that revealing other
codepoints outside the PCN-domain won't contravene the guidance given
in [RFC4774].
I wonder if this needs a bit more explanation about how to do this, or where to find more guidance?
4.3.1
Co-existence of PCN and not-PCN traffic
I wonder if it's worth adding pointer to S3.5 rfc5559 (or draft-ietf-pcn-marking-behaviour Section B.1) which says
>> It is not advised to have competing-non-PCN-traffic but, if there
is such traffic, there needs to be a mechanism to limit it.
"Competing-non-PCN-traffic" means traffic that shares a link with
PCN-traffic and competes for its forwarding bandwidth. Hence,
more competing-non-PCN-traffic results in poorer QoS for PCN.
Further, the unpredictable amount of competing-non-PCN-traffic
makes the PCN mechanisms less accurate and so reduces PCN's
ability to protect the QoS of admitted PCN-flows.
5
> The 11 codepoint in the ECN field MUST indicate PCN-marked (though
this does not exclude the 01 Experimental codepoint from carrying
the same meaning).
I think better would be " Experimental codepoint from also indicating PCN-marking" [it would indicate a 2nd level of pcn-marking, which you could say is not the "same" meaning]
A.1
The approach & wording is basically good.
>In PCN-domains with uniformly high link rates, the
appropriate DSCPs would currently be those for the Real Time Traffic
Class [RFC5127]. To be clear the PCN Working Group recommends using
admission control for the following service classes:
o Telephony (EF)
o Real-time interactive (CS4)
o Broadcast Video (CS3)
o Multimedia Conferencing (AF4)
I think "sufficient aggregation" would be better than "uniformly high link rates" [similarly, "sufficiently" not "highly" in the next para]
" Real Time Traffic Class" - 5127 calls it Treatment Aggregate, at least in Fig 2
you might want to say why CS5 is excluded from pcn (all the other dscps in the RT treatement aggregate are included]
rfc4594 needed as a ref somewhere here as that defines these dscps
Typos etc
Abstract
>This document specifies how such marks are to be encoded
delete 'to be'
4.0 >implementiors
4.2
> There are a number of factors that
were considered before choosing to set 10
could have a new paragraph before this
4.3.0
> Thirdly PCN
should be seen as being essentially a marking behaviour similar to
ECN but intended for inelastic traffic.
Re-phrase : Thirdly PCN is not a scheduling behaviour -- rather it should be seen as being essentially a marking behaviour similar to ECN but intended for inelastic traffic.
6
> in decapsulation
'upon' better?
6
> If an
operator wishes to allow ECN to exist end-to-end they must ensure
there are no tunnel end-points within the PCN-domain to prevent any
risk of PCN-markings being exposed to endpoints.
Earlier in the paragraph you talk about a tunnel across the pcn-domain - then there might be another tunnel wholly within the pcn-domain, and this would be ok. (I know what you mean - perhaps slight re-ordering of the para would do the trick)
A.1
>PCn region
PCN-domain
Thanks
phil
{ -----Original Message-----
{ From: pcn-bounces at ietf.org [mailto:pcn-bounces at ietf.org] On Behalf Of
{ toby.moncaster at bt.com
{ Sent: 20 August 2009 16:19
{ To: pcn at ietf.org; lars.eggert at nokia.com
{ Subject: [PCN] FW: New Version Notification fordraft-ietf-pcn-baseline-
{ encoding-05
{
{ I hope this accurately reflects the ML discussions over the past few days?
{ I have also corrected all the nits and hopefully haven't left any spelling
{ mistakes or typos...
{
{ Toby
{
{ ____________________________________________________________________
{ Toby Moncaster, <toby.moncaster at bt.com> Networks Research Centre, BT
{ B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 7918 901170
{
{
{
{ -----Original Message-----
{ From: IETF I-D Submission Tool [mailto:idsubmission at ietf.org]
{ Sent: 20 August 2009 16:17
{ To: Moncaster,T,Toby,DER3 R
{ Cc: Briscoe,RJ,Bob,DER3 R; menth at informatik.uni-wuerzburg.de
{ Subject: New Version Notification for draft-ietf-pcn-baseline-encoding-05
{
{
{ A new version of I-D, draft-ietf-pcn-baseline-encoding-05.txt has been
{ successfuly submitted by T Moncaster and posted to the IETF repository.
{
{ Filename: draft-ietf-pcn-baseline-encoding
{ Revision: 05
{ Title: Baseline Encoding and Transport of Pre-Congestion
{ Information
{ Creation_date: 2009-08-20
{ WG ID: pcn
{ Number_of_pages: 14
{
{ Abstract:
{ The objective of Pre-Congestion Notification (PCN) is to protect the
{ quality of service (QoS) of inelastic flows within a Diffserv domain.
{ The overall rate of the PCN-traffic is metered on every link in the
{ PCN-domain, and PCN-packets are appropriately marked when certain
{ configured rates are exceeded. The level of marking allows the
{ boundary nodes to make decisions about whether to admit or block a
{ new flow request, and (in abnormal circumstances) whether to
{ terminate some of the existing flows, thereby protecting the QoS of
{ previously admitted flows. This document specifies how such marks
{ are to be encoded into the IP header by re-using the Explicit
{ Congestion Notification (ECN) codepoints within this controlled
{ domain. The baseline encoding described here provides for only two
{ PCN encoding states, Not-marked and PCN-marked.
{
{
{
{ The IETF Secretariat.
{
{
{ _______________________________________________
{ PCN mailing list
{ PCN at ietf.org
{ https://www.ietf.org/mailman/listinfo/pcn