Subject: Re: [PCN] PCN Marking behaviour draft

From: <[email-masked]>
Date: Tue, 6 May 2008 16:45:19 +0100

Fortune

Thanks for your comments!

Some follow-ups in-line, indicated by [phil]

phil

-----Original Message-----
From: Eardley,PL,Philip,CXR9 R 
Sent: 06 May 2008 12:15
To: Eardley,PL,Philip,CXR9 R
Subject: 

Hi Philip et al,

I am resending the comments below because Tina said she hasn't received
my last email with the same comments.

And I don't know why my last email hasn't been archived in the PCN
mailing list.

A few comments below:

Comment 1:

In section 1, I think the use cases are based on the following
assumptions: a) Flow 

termination and admission control can be deployed independently. b) Both
threshold-marking 

and excess-traffic-marking are applicable for admission control. c) Only
excess-traffic-marking 

is applicable for flow termination, and threshold-marking is not
applicable for flow termination.

I would like to know if these assumptions are correct in you view. 

And I suggest we add the assumptions into section 1, just to provide
more support to the 

sentense "This leads to the following four use cases".

[phil] yes, you're right. I'll try to make this clearer. 

Comment 2:

I am wondering if the following use case is acceptable, because I think
it obeys my 

assumptions above: An operator requires only admission control, and
excess-traffic-marking is used.

And this is not included in section 1 in the current draft.

[phil] in theory this is possible. However, the real limitation in this
case is that you only have two encoding states (PCN-marked & not
PCN-marked) - then you'd use threshold-marking, as this is more accurate
for admission control than excess-traffic-marking. However, I should add
this in somehow. 

Comment 3:

I am a little confused by the descriptions of use case 3 and 4 in
section 1.

I don't know why two encoding states are needed in use case 3, while
only 1 encoding states 

are needed in use case 4. Suppose admission control need two states, one
is ADMISSION(as default), 

the other is ADMISSION-STOP. I think in the same way, flow termination
need two states, one is 

TERMINATION, the other is TERMINATION-STOP(as default). If the default
state should be excluded, 

then admission control only need one state called ADMISSION-STOP, while
flow termination only 

need one state called TERMINATION.

[phil] yes, sorry this is confusing. I made a typo. Use case 4 should
say that 2 encoding states are needed, ie excess-traffic-marked & "not
PCN-marked"

Comment 4:

The condition function is introduced into the draft. I think this is the
function belonging 

to the PCN-interior-node. Maybe we can add this funciton to the
draft-PCN-architecture.

[phil] yes, this is a good point. Thanks. 

Comment 5:

Something like the first 4 sentenses of the section 2.4 can also be
mentioned in section 2.3.

[phil] no, the two sections are deliberately different.

First some context for other people. Section 2.3 is about the Threshold
meter function & S2.4 about the Excess traffic meter function. The first
few sentences of S2.4 explain that the Excess traffic meter shouldn't
meter pkts that are already excess-traffic-marked. 
 
Your suggestion is that S2.3 similarly says that the Threshold meter
function shouldn't meter pkts that are already threshold marked (or
perhaps excess-traffic-marked). This would be wrong - remember that the
marked pkts come from admitted flows and cause load on the router, so
must contribute to the decision about whether a new flow is blocked or
admitted.
To illustrate this, consider a contrived scenario. There's a high speed
router with a 1Gb/s PCN-threshold-rate. The total traffic is above this,
so all the pkts are threshold-marked. The traffic gets split over many
small links (a big fan out) and mixed with lots of other traffic that
has gone through other routers that aren't doing any marking, such that
another node seems 1Mb/s of threshold marks. This node actually has a
total traffic of 10Mb/s and a threshold rate of 9.1Mb/s. 1Mb/s is
already marked - so with your proposal it will only meter 9M/s & hence
not mark any more pkts. If there's a PCN egress at the end of this link
it sees 10% of traffic as threshold marked, which may not be enough to
trigger blocking of new flows. Yet really the traffic is well above its
threshold rate, so really no more flows should be admitted. This is
achieved if the node meters all pkts, ie including ones already marked,
as then it ends up threshold marking all pkts.
 
Things are different for the excess traffic meter, because the PCN edges
nodes react to the amount of excess-traffic-markings to determine how
much traffic to terminate.  
 
S2.4 also says that if a PCN-interior-node drops a pkt, then it
shouldn't contribute to the excess-traffic-meter. There's no need to say
something similar for the threshold meter - if the load is high enough
for pkts to be dropped, then we know for sure that the traffic is way
above the PCN-threshold-rate and therefore all pkts are getting
threshold-marked or excess-traffic-marked. 
 
I'll add some explanation to the Appendix to cover these points. 

Comment 6:

In section 4.5 in draft-PCN-architecture, it says "There may be other
traffic with the same priority 

as PCN-traffic.". This kind of traffic is not very clear to me whether
it affects PCN-meter. 

Could you clarify it, please?

[phil] this needs clarifying. Joe and I have been discussing this, as we
realised whilst writing this draft that this text is problematic. Will
send something soon

Best Regards,

Fortune

----- Original Message ----- 

From: [email-masked] 

To: [email-masked] 

Sent: Tuesday, April 29, 2008 10:40 PM

Subject: [PCN] PCN Marking behaviour draft

Hi

I've just posted a draft which tries to specify the marking behaviour
for PCN nodes.

It's based on an update of the emails I sent shortly before the last
IETF. Updates include adjusting as a result of the WG consensus call on
Steven's Questions 1 to 6. Many thanks to Joe, Michael & Anna who've
made suggestions and comments about it. Overall I think it's much
improved compared to the emails.

Comments please!

Thanks

Phil/.

 

-----Original Message-----

From: IETF I-D Submission Tool [mailto:[email-masked]] 

Sent: 29 April 2008 15:33

To: Eardley,PL,Philip,CXR9 R

Subject: New Version Notification for
draft-eardley-pcn-marking-behaviour-00 

 

A new version of I-D, draft-eardley-pcn-marking-behaviour-00.txt has
been successfuly submitted by Philip Eardley and posted to the IETF
repository.

Filename:   draft-eardley-pcn-marking-behaviour

Revision:   00

Title:            Marking behaviour of PCN-nodes

Creation_date:    2008-04-29

WG ID:            Independent Submission

Number_of_pages: 15

Abstract:

This document standardises the two marking behaviours of PCN-nodes:

threshold marking and excess traffic marking.  Threshold marking

marks all PCN-packets if the PCN traffic rate is greater than a first

configured rate.  Excess traffic marking marks a proportion of PCN-

packets, such that the amount marked equals the traffic rate in

excess of a second configured rate.Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this

document are to be interpreted as described in RFC 2119 [RFC2119].

 

 

The IETF Secretariat.

 

 

------------------------------------------------------------------------
--------

_______________________________________________

PCN mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/pcn

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