Subject: RE: [PCN] FW: I-D ACTION:draft-babiarz-pcn-3sm-00.txt

From: <[email-masked]>
Date: Mon, 1 Oct 2007 16:16:35 +0100

Hi Joe (All)

Sorry about the late comments but my attention was recently drawn to
this draft and in particular its approach to simulate threshold marking.

Appendix A.6 suggests that a single rate three colour marker can be used
to perform threshold marking.

I think this is not true.

If you configure the srTCM in the way suggested it will mark exactly the
same packets as a single token bucket of length MBS doing tail marking.
It is true that the fill level of the E bucket will correctly track the
fill level of the larger token bucket (of length TB.size) that we are
trying to emulate.  However, the fill level of the E bucket does not
affect the marking which will be done if and only if the C bucket is at
its tail.  Thus the setup becomes equivalent to the C bucket alone.

HTH

Ben Strulo

> -----Original Message-----
> From: Jozef Babiarz [mailto:[email-masked]] 
> Sent: 03 July 2007 18:18
> To: [email-masked]
> Subject: [PCN] FW: I-D ACTION:draft-babiarz-pcn-3sm-00.txt
> 
> 
> Hi all,
> In an email below there is a link to 00 version of pcn-3sm 
> draft that defines metering and marking for admission control 
> and flow termination. We call it three state PCN marking 
> because there are three conditions, packets are not marked, 
> packets marked to indicate that admission of additional flows 
> should be stopped and finally condition where flows are 
> marked to indicate that termination is needed. This draft 
> incorporates the metering and marking approach for flow 
> termination that was defined in 
> draft-babiarz-pcn-explicit-marking-00. 
> 
> Simulation results for the proposed "AR-metering and 
> AS-re-marking" and "SR-metering and ET-re-marking" will be 
> published in a separate draft.
> 
> Regards, Joe
> email:[email-masked]
> Telephone:613-763-6098
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: July 3, 2007 11:15 AM
> To: [email-masked]
> Subject: I-D ACTION:draft-babiarz-pcn-3sm-00.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
> 
> 	Title		: Three State PCN Marking
> 	Author(s)	: J. Babiarz, et al.
> 	Filename	: draft-babiarz-pcn-3sm-00.txt
> 	Pages		: 24
> 	Date		: 2007-7-3
> 	
>    This document proposes metering and marking mechanisms for PCN-
>    enabled nodes to label packets with pre-congestion 
> information.  The
>    marker marks all PCN packets with an admission-stop (AS) 
> codepoint if
>    the PCN traffic rate on a link exceeds its admissible rate (AR) and
>    when it exceeds its supportable rate (SR), it marks some of those
>    packets exceeding SR with an excess-traffic (ET) codepoint.  The
>    flows with ET-marked packets will be terminated until the aggregate
>    PCN traffic on the path decreases below its SR.  This document
>    proposes metering and marking mechanisms for these objectives.
> 
> 
> A URL for this Internet-Draft is: 
> http://www.ietf.org/internet-drafts/draft-babiarz-pcn-3sm-00.txt
> 
> To remove yourself from the I-D Announcement list, send a message to 
> [email-masked] with the word unsubscribe in 
> the body of 
> the message. 
> You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce 
> to change your subscription settings.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the 
> username "anonymous" and a password of your e-mail address. After 
> logging in, type "cd internet-drafts" and then 
> "get draft-babiarz-pcn-3sm-00.txt".
> 
> A list of Internet-Drafts directories can be found in 
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-babiarz-pcn-3sm-00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 
> Below is the data which will enable a MIME compliant mail 
> reader implementation to automatically retrieve the ASCII 
> version of the Internet-Draft.
> 

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

---

From: "Jozef Babiarz" <[email-masked]>
Date: Wed, 3 Oct 2007 14:32:10 -0400

Hi Ben,
Thanks for catching this error in the draft as very few people look at
the appendix very carefully.

I will try to go through RFC2697 section 3 below to make sure I
understand the issue. Comments denoted by [PCN comment] are my
explanations for threshold marking for admission control.

Taken form RFC2697.

3. Metering

   The behavior of the Meter is specified in terms of its mode and two
   token buckets, C and E, which both share the common rate CIR.  The
   maximum size of the token bucket C is CBS and the maximum size of the
   token bucket E is EBS.

   The token buckets C and E are initially (at time 0) full, i.e., the
   token count Tc(0) = CBS and the token count Te(0) = EBS.  Thereafter,
   the token counts Tc and Te are updated CIR times per second as
   follows:

     o If Tc is less than CBS, Tc is incremented by one, else

     o if Te is less then EBS, Te is incremented by one, else

     o neither Tc nor Te is incremented.

   When a packet of size B bytes arrives at time t, the following
   happens if the srTCM is configured to operate in the Color-Blind
   mode:

     o If Tc(t)-B >= 0, the packet is green and Tc is decremented by B
       down to the minimum value of 0, else
[PCN Comment]When the above is true, packets are green (not AS-marked)
[PCN Comment]When Tc(t)-B >= 0 is not true than the below statement is
tested.
     o if Te(t)-B >= 0, the packets is yellow and Te is decremented by B
       down to the minimum value of 0, else
[PCN Comment]When the above is true, packets are marked yellow
(AS-marked). 

     o the packet is red and neither Tc nor Te is decremented.
[PCN Comment] Packet is AS-marked.

I think I see the problem, when tokens are added to Tc and Te, the
addition of tokens is to Tc first. This may cause the next packet to be
green if the addition of tokens is greater than the size of next packet.
This is not equivalent to the behavior for AR-Meter and AS-Marker in
section 2.2.2. We will update the draft indicating that some changes to
pseudo code of srTCM are required to produce equivalent behavior. 

I think if we change the order at which we add tokens to the token
bucket will fix the problem. If we add tokens to Te first that should
produce similar behavior to section 2.2.2.

o if Te is less than EBS, Te is incremented by one, else
o If Tc is less than CBS, Tc is incremented by one, else
o neither Tc nor Te is incremented.

Let me know if you agree.

Regards, Joe
email:[email-masked]
Telephone:613-763-6098

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: October 1, 2007 11:17 AM
To: Babiarz, Jozef (CAR:0S03); [email-masked]
Subject: RE: [PCN] FW: I-D ACTION:draft-babiarz-pcn-3sm-00.txt

Hi Joe (All)

HTH

Ben Strulo

---

From: Michael Menth <[email-masked]>
Date: Wed, 03 Oct 2007 22:12:38 +0200

Hi Ben,

thanks for notifying us! You are right, there is a mistake in A.6 of
http://www.ietf.org/internet-drafts/draft-babiarz-pcn-3sm-00.txt

CBS = MBS is correct, but we need
EBS = TB.size - MBS (instead of EBS = TB.size)

Then it should work. Can you check that, please? Please let us know!

Regards,

    Michael

-- 
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/888-6644, fax: (+49)-931/888-6632
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn

---

From: <[email-masked]>
Date: Thu, 4 Oct 2007 09:42:21 +0100

Hi Michael

No that doesn't work either.

The gist is that the C bucket controls the marking on its own and
changing the E bucket has no effect on the C bucket.  Just think about
the way the C bucket goes up and down and you can see that the level in
the E bucket has no effect on it.

The E bucket does control whether the colouring is yellow or red. But
that does not change the marking.

Ben

> From: Michael Menth [mailto:[email-masked]] 
> Sent: 03 October 2007 21:13
> To: Strulo,B,Ben,CXR9 R
> Cc: [email-masked]; [email-masked]; Xiao-Gao (Leo) Liu
> Subject: Re: [PCN] FW: I-D ACTION:draft-babiarz-pcn-3sm-00.txt
> 
> 
> Hi Ben,
> 
> > Appendix A.6 suggests that a single rate three colour marker can be 
> > used to perform threshold marking.
> >
> > If you configure the srTCM in the way suggested it will 
> mark exactly 
> > the same packets as a single token bucket of length MBS doing tail 
> > marking. It is true that the fill level of the E bucket 
> will correctly 
> > track the fill level of the larger token bucket (of length TB.size) 
> > that we are trying to emulate.  However, the fill level of the E 
> > bucket does not affect the marking which will be done if 
> and only if 
> > the C bucket is at its tail.  Thus the setup becomes 
> equivalent to the 
> > C bucket alone.
> >
> > HTH
> >
> > Ben Strulo
> >
> >

---

From: Michael Menth <[email-masked]>
Date: Thu, 04 Oct 2007 19:40:17 +0200

Hi Ben,

we can view the two token buckets of RFC 2697 as a decomposition of one 
large token bucket when we put the token bucket C on top of token bucket E:

+ C.full, VQ.empty
|
| token bucket C, rate: CIR, size CBS: marking: green=no admission-stop
|
+ C.empty, E.full, VQ.markingThreshold
|
|
| token bucket E, rate: CIR, size EBS: marking: yellow=admission-stop
|
|
+ E.empty, VQ.full

Look at the corresponding virtual queue (turn the whole thing upside down):
VQ.rate=CIR
VQ.size=EBS+CBS
VQ.markingThreshold=CBS

I hope that this equivalence is right and obvious. Do you agree or is 
there a mistake I have overlooked? This is what we wanted to express in 
the 3sm draft.

BTW, the descriptive text in A.6 is wrong, but it is consistent with the 
flaw we detected yesterday:

> If it is conform to (CIR, EBS), it is colored yellow.
>   
=>

> If it is conform to (CIR, EBS+CBS), it is colored yellow.
>                              ^^^^
>   

But what's the impact of EBS on the marking behavior? The size of EBS 
(or VQ.size-VQ.markingThreshold) controls the marking behavior in 
overload situations. Consider the long-term PCN rate is larger than CIR, 
but due to short-time fluctuations it is smaller than CIR for a while. 
If EBS is small, Te (fill state of token bucket E) increases, E fills 
up, and the algorithm stops marking. If EBS is large, it takes longer 
until short-time fluctuations stop the marking. We almost finished a 
study giving insight into the impact of the parameters on the marking 
behavior in different scenarios. We'll send it to the list when it's done.

Regards,

    Michael

[email-masked] wrote:
>>> Sorry about the late comments but my attention was recently 
>>>       
>> drawn to 
>>     
>>>>    the PCN traffic rate on a link exceeds its admissible 
>>>>         
>> rate (AR) and
>>     
>>>>    when it exceeds its supportable rate (SR), it marks 
>>>>         
>> some of those
>>     
>>>>    flows with ET-marked packets will be terminated until 
>>>>         
>> the aggregate
>>     
>>>> To remove yourself from the I-D Announcement list, send a 
>>>>         
>> message to
>>

---

From: Michael Menth <[email-masked]>
Date: Thu, 04 Oct 2007 23:28:17 +0200

Hi Ben,

after a short discussion with Joe: srTCM in RFC 2697 is not able to 
approximate threshold marking and the arguments provided in his last 
emails are absolutely correct.

srTCM first refills token bucket C and if this is full it continues to 
refill E. I falsely thought that first token bucket E is refilled and 
then C. This is not the case, but necessary for our approximation of 
threshold marking by srTCM. We will correct this bug in 3sm. Thanks for 
reading and for pointing us to this fault!

Regards,

    Michael

Michael Menth wrote:
> Hi Ben,
>
> we can view the two token buckets of RFC 2697 as a decomposition of 
> one large token bucket when we put the token bucket C on top of token 
> bucket E:
>
> + C.full, VQ.empty
> |
> there a mistake I have overlooked? This is what we wanted to express 
> in the 3sm draft.
>
> BTW, the descriptive text in A.6 is wrong, but it is consistent with 
> the flaw we detected yesterday:
>
> overload situations. Consider the long-term PCN rate is larger than 
> CIR, but due to short-time fluctuations it is smaller than CIR for a 
> while. If EBS is small, Te (fill state of token bucket E) increases, E 
> fills up, and the algorithm stops marking. If EBS is large, it takes 
> longer until short-time fluctuations stop the marking. We almost 
> finished a study giving insight into the impact of the parameters on 
> the marking behavior in different scenarios. We'll send it to the list 
> when it's done.
>
> Regards,
>
>    Michael
>
>
> [email-masked] wrote:
>> Hi Michael
>>
>>> From: Michael Menth [mailto:[email-masked]] Sent: 
>>> 03 October 2007 21:13
>>> To: Strulo,B,Ben,CXR9 R
>>>>> draft that defines metering and marking for admission control and 
>>>>> flow termination. We call it three state PCN marking because there 
>>>>> are three conditions, packets are not marked, packets marked to 
>>>>> indicate that admission of additional flows should be stopped and 
>>>>> finally condition where flows are marked to indicate that 
>>>>> termination is needed. This draft incorporates the metering and 
>>>>> marking approach for flow termination that was defined in 
>>>>> [email-masked] with the word unsubscribe in the 
>>>>> body of the message. You can also visit 
>>>>> https://www1.ietf.org/mailman/listinfo/I-D-announce to change your 
>>>>> subscription settings.
>>>>>
>>>>> logging in, type "cd internet-drafts" and then "get 
>>>>> draft-babiarz-pcn-3sm-00.txt".
>>>>>
>>>>> http://www.ietf.org/shadow.html or 
>>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>>>
>>>>> reader implementation to automatically retrieve the ASCII version 
>>>>> of the Internet-Draft.
>>>>>
>>>>>