Subject: [CDNi] Comments on: draft-caulfield-cdni-rate-pacing-00.txt

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Wed, 6 Nov 2013 04:02:36 +0000

Hi Matt,

1)
"
No value needs to be advertised for this capability and therefore no additional value registry need to be defined.
"
Would it be a good idea to define a value registry with a single value today (e.g. "token-bucket/v1") to facilitate future extensibility in case it is useful to define other rate-pacing methods (eg with a different algorithm, with a max rate,…)?

2)
"
3.2.  Request Routing Redirection Interface
   A new RatePacing metadata object is defined to represent the
   configuration for rate pacing. 
"
There seems to be some cut-and-paste issue or something as the RI section contains text that is relevant to MI (and is a dupliacte of it).

3)
"
A malicious CSP might attempt to use rate pacing to instruct a dCDN
   to delivery some content at a very high rate thereby amplifying a
   DDOS attack.  The decision to enforce a rate is left to the
   discretion of a dCDN.  An implementation of rate pacing should
   implement reasonable upper bound to avoid such cases.
"
I don't get the issue.

First, rate-pacing is only intended as an upper-limit when the dCDN is in a position to send at a higher rate than that. It is not intended as an encouragement to send any faster dCDN would have transmitted otherwise. So to me, requesting a rate-pacing of infitine rate is simply equivalent to not using rate-pacing at all. 

Secondly, a CSP is typically charged by uCDN for dCDN deliveries. So if the CSP is requesting uCDN/dCDN to transmit a lot of content as fast as possible, this is all good news for the uCDN and dCDN. 

Cheers

Francois

On 22 Oct 2013, at 13:31, [email-masked] wrote:

> You posted a new draft today. In the interest of informing your
> Cisco colleagues, would you be so kind as to fill the rest of us
> in on your project and what the draft is about?
> 
> The file may be found online at
> 	http://tools.ietf.org/html/draft-caulfield-cdni-rate-pacing-00.txt.
> 
> By the way: if you know of a CPOL that might relate to this,
> and you have not done so, would you please access
> http://wwwin-eng.cisco.com/pcb/standards/csrt.cgi to register
> the relationship between the CPOL and the draft?
> 
> The abstract you included reads:
>      Rate pacing is a class of network traffic shaping which limits the
>      transmission rate of data over a network.  This document defines CDNI
>      extensions for downstream CDNs to support rate pacing on behalf of
>      upstream CDNs.
> 
> 
> There is more background at http://wwwin-people/fred/explanation.html
> 
> By the way, if you're not on ietf-interest, you may find it an
> interesting list to join.
>

---

From: "Matt Caulfield (mcaulfie)" <[email-masked]>
Date: Wed, 6 Nov 2013 04:18:30 +0000

Hi Francois,

Thank you for the comments. Please see my responses inline.	

Regards,
Matt

-----Original Message-----
From: Francois Le Faucheur (flefauch) 
Sent: Tuesday, November 05, 2013 8:03 PM
To: Matt Caulfield (mcaulfie)
Cc: [email-masked]
Subject: Comments on: draft-caulfield-cdni-rate-pacing-00.txt 

Hi Matt,

1)
"
No value needs to be advertised for this capability and therefore no additional value registry need to be defined.
"
Would it be a good idea to define a value registry with a single value today (e.g. "token-bucket/v1") to facilitate future extensibility in case it is useful to define other rate-pacing methods (eg with a different algorithm, with a max rate,...)?

[Matt] I think there are two options: 1) Change this rate pacing draft to make it more extensible and define a registry as your describe, or 2) Change the name of this draft to CDNI Token Bucket Rate Pacing and require that proponents of alternative rate pacing algorithms create their own drafts. Which is better from an IETF perspective?

2)
"

[Matt] Yes, definitely a cut-and-paste issue. I will fix that in the next revision. The text should have been:
" The RRI is not impacted by rate pacing. However, if the metadata for a piece of content indicates that rate pacing is desired, then a request router should only redirect requests for that content to CDNs which advertise "RatePacing" as a capability."

3)
"

[Matt] Good points - I think I can remove this security consideration. However, regarding rate pacing as only an upper limit - this is never stated explicitly. Should we call this out in the draft? Right now, section #2 includes the phrase: " the traffic shape MUST fit within the same envelope of a token bucket algorithm." 

Cheers

Francois

On 22 Oct 2013, at 13:31, [email-masked] wrote:

> You posted a new draft today. In the interest of informing your Cisco 
> colleagues, would you be so kind as to fill the rest of us in on your 
> project and what the draft is about?
> 
> By the way: if you know of a CPOL that might relate to this, and you 
> have not done so, would you please access 
> http://wwwin-eng.cisco.com/pcb/standards/csrt.cgi to register the 
> relationship between the CPOL and the draft?
>

---

From: Scott Leibrand <[email-masked]>
Date: Tue, 5 Nov 2013 20:25:44 -0800

> On Nov 5, 2013, at 8:02 PM, "Francois Le Faucheur (flefauch)" <[email-masked]> wrote:
> 
> Hi Matt, 
> 
> 3)
> "

The problem is actually the reverse. If the CSP wants to DDoS the CDN, they can actually set the pacing to an absolute trickle. That leaves too many connections open on the CDN's servers, thereby exhausting server state resources. To prevent that, CDNs can configure a minimum pacing rate that they will honor. 

-Scott

> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni

---

From: Kevin J Ma <[email-masked]>
Date: Tue, 5 Nov 2013 23:39:03 -0500

> to define other rate-pacing methods (eg with a different
> algorithm, with a max rate,...)?
>
> [Matt] I think there are two options: 1) Change this rate pacing draft to
> make it more extensible and define a registry as your describe, or 2)
> Change the name of this draft to CDNI Token Bucket Rate Pacing and require
> that proponents of alternative rate pacing algorithms create their own
> drafts. Which is better from an IETF perspective?
...
> [Matt] ... Right now,
> section #2 includes the phrase: " the traffic shape MUST fit within the
> same envelope of a token bucket algorithm."

I actually found the "MUST fit within the same envelope" part confusing the
first time i read through the draft.  If the intent is to have all the dCDNs
provide substantially the same functionality, then I think it would be better
to make the GenericMetadata object associated with this capability token
bucket specific.  I initially interpreted the generic "rate" and "size"
properties to be applicable to any random algorithm which may not have the
same envelope as a token bucket.  Another option might be to have a registry
of allowable groups of algorithms with acceptably similar performance envelopes,
though that may be going a bit far?  ;)

--  Kevin J. Ma

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Matt Caulfield (mcaulfie)
> Sent: Tuesday, November 05, 2013 11:19 PM
> To: Francois Le Faucheur (flefauch)
> Cc: [email-masked]
> Subject: Re: [CDNi] Comments on: draft-caulfield-cdni-rate-pacing-00.txt
> 
> Hi Francois,
> 
> No value needs to be advertised for this capability and therefore no
> additional value registry need to be defined.
> "
> Would it be a good idea to define a value registry with a single value
> today (e.g. "token-bucket/v1") to facilitate future extensibility in case
> it is useful to define other rate-pacing methods (eg with a different
> algorithm, with a max rate,...)?
> 
> [Matt] I think there are two options: 1) Change this rate pacing draft to
> make it more extensible and define a registry as your describe, or 2)
> Change the name of this draft to CDNI Token Bucket Rate Pacing and require
> that proponents of alternative rate pacing algorithms create their own
> drafts. Which is better from an IETF perspective?
> 
> 
> 2)
> "
> There seems to be some cut-and-paste issue or something as the RI section
> contains text that is relevant to MI (and is a dupliacte of it).
> 
> " The RRI is not impacted by rate pacing. However, if the metadata for a
> piece of content indicates that rate pacing is desired, then a request
> router should only redirect requests for that content to CDNs which
> advertise "RatePacing" as a capability."
> 
> 
> 3)
> "
> First, rate-pacing is only intended as an upper-limit when the dCDN is in
> a position to send at a higher rate than that. It is not intended as an
> encouragement to send any faster dCDN would have transmitted otherwise. So
> to me, requesting a rate-pacing of infitine rate is simply equivalent to
> not using rate-pacing at all.
> 
> Secondly, a CSP is typically charged by uCDN for dCDN deliveries. So if
> the CSP is requesting uCDN/dCDN to transmit a lot of content as fast as
> possible, this is all good news for the uCDN and dCDN.
> 
> [Matt] Good points - I think I can remove this security consideration.
> However, regarding rate pacing as only an upper limit - this is never
> stated explicitly. Should we call this out in the draft? Right now,
> section #2 includes the phrase: " the traffic shape MUST fit within the
> same envelope of a token bucket algorithm."
> 
> 
> Cheers
> 
> Francois
> 
>