Subject: Re: [CDNi] New Version Notification for draft-caulfield-cdni-rate-pacing-02.txt

From: "Kent Leung (kleung)" <[email-masked]>
Date: Tue, 11 Nov 2014 00:23:44 +0000

Hi Matt. Just wondering if this supports the case when uCDN wants the dCDN to perform rate pacing only when delivering over a mobile network but use "normal" delivery over other access networks?

Kent

-----Original Message-----
From: CDNi [mailto:[email-masked]] On Behalf Of Matt Caulfield (mcaulfie)
Sent: Monday, October 27, 2014 2:03 PM
To: [email-masked]
Subject: [CDNi] FW: New Version Notification for draft-caulfield-cdni-rate-pacing-02.txt

This new version of the rate pacing draft incorporates comments from Francois sent prior to the London meeting (March 2014).

Cheers,
Matt

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, October 27, 2014 4:58 PM
To: Matt Caulfield (mcaulfie); Matt Caulfield (mcaulfie)
Subject: New Version Notification for draft-caulfield-cdni-rate-pacing-02.txt

A new version of I-D, draft-caulfield-cdni-rate-pacing-02.txt
has been successfully submitted by Matt Caulfield and posted to the
IETF repository.

Name:		draft-caulfield-cdni-rate-pacing
Revision:	02
Title:		CDNI Rate Pacing
Document date:	2014-10-27
Group:		Individual Submission
Pages:		8
URL:            http://www.ietf.org/internet-drafts/draft-caulfield-cdni-rate-pacing-02.txt
Status:         https://datatracker.ietf.org/doc/draft-caulfield-cdni-rate-pacing/
Htmlized:       http://tools.ietf.org/html/draft-caulfield-cdni-rate-pacing-02
Diff:           http://www.ietf.org/rfcdiff?url2=draft-caulfield-cdni-rate-pacing-02

Abstract:
   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.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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

---

From: Kevin Ma J <[email-masked]>
Date: Tue, 11 Nov 2014 00:26:13 +0000

could do it with different mobile/non-mobile URIs?
with the pacing metadata only on the mobile URIs?

> From: CDNi [mailto:[email-masked]] On Behalf Of Kent Leung (kleung)
> Sent: Monday, November 10, 2014 7:24 PM
> To: Matt Caulfield (mcaulfie); [email-masked]
> Subject: Re: [CDNi] New Version Notification for draft-caulfield-cdni-rate-
> pacing-02.txt
> 
> Hi Matt. Just wondering if this supports the case when uCDN wants the dCDN
> to perform rate pacing only when delivering over a mobile network but use
> "normal" delivery over other access networks?
> 
> Kent
> 
> This new version of the rate pacing draft incorporates comments from
> Francois sent prior to the London meeting (March 2014).
> 
> Cheers,
> Matt
>

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Tue, 11 Nov 2014 00:31:52 +0000

OK. That's one way to accomplish that. Should that be the only way?

Kent

-----Original Message-----
From: Kevin Ma J [mailto:[email-masked]] 
Sent: Monday, November 10, 2014 4:26 PM
To: Kent Leung (kleung); Matt Caulfield (mcaulfie); [email-masked]
Subject: RE: New Version Notification for draft-caulfield-cdni-rate-pacing-02.txt

> Subject: Re: [CDNi] New Version Notification for 
> draft-caulfield-cdni-rate- pacing-02.txt
> 
> Hi Matt. Just wondering if this supports the case when uCDN wants the 
> dCDN to perform rate pacing only when delivering over a mobile network 
> but use "normal" delivery over other access networks?
> 
> Kent
> 
> Subject: [CDNi] FW: New Version Notification for 
> draft-caulfield-cdni-rate- pacing-02.txt
> 
> Subject: New Version Notification for 
> draft-caulfield-cdni-rate-pacing- 02.txt
> 
> 
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Tue, 11 Nov 2014 03:04:11 +0000

Other conceivable ways could be to extend the rate-pacing metadata with the ability:
	(i) to specifiy different rate-pacing control parameters for different types of access network (and it would then be up to the dCDN to determine which request comes on which type of access network); or 
	(ii) to specifiy different rate-pacing control parameters for different “footprints" 

> On 10 Nov 2014, at 14:31, Kent Leung (kleung) <[email-masked]> wrote:
>

---

From: "Matt Caulfield (mcaulfie)" <[email-masked]>
Date: Tue, 11 Nov 2014 14:31:58 +0000

Could the ability to apply specific metadata based on access network type be more general than just rate pacing?

It sounds like we could consider introducing a feature to the metadata interface which allows a dCDN to not only look up metadata based on URI but also based on the type of access network.

Or is this really something which is specific to rate pacing?

> From: Francois Le Faucheur (flefauch)
> Sent: Monday, November 10, 2014 10:04 PM
> To: Kent Leung (kleung)
> Cc: Francois Le Faucheur (flefauch); Ma Kevin; Matt Caulfield (mcaulfie);
> [email-masked]
> Subject: Re: [CDNi] New Version Notification for draft-caulfield-cdni-
> rate-pacing-02.txt
> 
> 	(i) to specifiy different rate-pacing control parameters for
> different types of access network (and it would then be up to the dCDN
> to determine which request comes on which type of access network); or
> >> From: CDNi [mailto:[email-masked]] On Behalf Of Matt
> Caulfield
> >> (mcaulfie)
> >> Htmlized:       http://tools.ietf.org/html/draft-caulfield-cdni-rate-
> pacing-
> >> 02

---

From: <[email-masked]>
Date: Tue, 11 Nov 2014 17:08:43 +0000

Hey,

Certainly from a operators perspective, enabling rate pacing / setting the algorith per footprint is more attractive than a binary mobile / non-mobile. We have use cases to rate pace on wired connected subscribers as well. In addition, setting the actual pacing value per content uri / content uri regex / content 'type' / content provider are also all valid. Not sure if that makes it a bit complication though!

Regards

Mal

-----Original Message-----
From: CDNi [mailto:[email-masked]] On Behalf Of Francois Le Faucheur (flefauch)
Sent: 10 November 2014 17:04
To: Kent Leung (kleung)
Cc: [email-masked]
Subject: Re: [CDNi] New Version Notification for draft-caulfield-cdni-rate-pacing-02.txt

>> dCDN to perform rate pacing only when delivering over a mobile 
>> network but use "normal" delivery over other access networks?
>> 
>> Kent
>>

---

From: Kevin Ma J <[email-masked]>
Date: Tue, 11 Nov 2014 18:46:46 +0000

Hi Mal,

  CDNI Metadata is indexed on URI, so, a URI-based scheme would actually be ideal, imo.
  I don't see a technical issue with having different URIs correspond to different pacing rates.
  (assuming the metadata is reasonable, i.e., not a different rate for every asset in the CDN)

--  Kevin J. Ma

> From: CDNi [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Tuesday, November 11, 2014 12:09 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Certainly from a operators perspective, enabling rate pacing / setting the
> algorith per footprint is more attractive than a binary mobile / non-mobile.
> We have use cases to rate pace on wired connected subscribers as well. In
> addition, setting the actual pacing value per content uri / content uri
> regex / content 'type' / content provider are also all valid. Not sure if
> that makes it a bit complication though!
> 
> Regards
> 
> Mal
> 
> different types of access network (and it would then be up to the dCDN to
> determine which request comes on which type of access network); or
> >> Status:         https://datatracker.ietf.org/doc/draft-caulfield-cdni-
> rate-
> >> pacing/
> >> Diff:           http://www.ietf.org/rfcdiff?url2=draft-caulfield-cdni-
> rate-
> >> pacing-02
> >>
> >> Abstract:

---

From: "Matt Caulfield (mcaulfie)" <[email-masked]>
Date: Wed, 12 Nov 2014 15:28:38 +0000

Right - the more I think about it, I think the URI solution is reasonable.

The content provider can redirect the client to the most appropriate URI for their device.

> From: CDNi [mailto:[email-masked]] On Behalf Of Kevin Ma J
> Sent: Tuesday, November 11, 2014 1:47 PM
> To: [email-masked]; Francois Le Faucheur (flefauch); Kent Leung
> (kleung)
> Cc: [email-masked]
> > From: CDNi [mailto:[email-masked]] On Behalf Of Francois Le
> Faucheur
> > (flefauch)
> > Other conceivable ways could be to extend the rate-pacing metadata
> with the
> > ability:
> > >> From: CDNi [mailto:[email-masked]] On Behalf Of Kent
> Leung
> > >> (kleung)

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Tue, 18 Nov 2014 06:10:40 +0000

Hi Matt,

(as an individual)

In any cases, I recommend that you add some text in the next rev capturing how the rate-pacing capability as currently described can be combined with the use of different URIs allocated by the portal to different requests, in order to achieve different rate-pacing rates (or different rate-pacing algorithms if/when addituional ones are specified) for different request profiles.
You could also give the example of a scenario where different URIs (and therefore different rate-pacing rates) are applied to requests based on device types (as extracted from HTTP headers).

With respect to the initial usecase of applying different rate-pacing rates depending on different access networks, do you feel it is always/generally feasible to determine the access network based on information available in the initial content request, given many devices are capable of using various access types ?

Cheers

Francois

> On 12 Nov 2014, at 07:28, Matt Caulfield (mcaulfie) <[email-masked]> wrote:
>

---

From: "Matt Caulfield (mcaulfie)" <[email-masked]>
Date: Tue, 18 Nov 2014 21:08:24 +0000

Hi Francois,

Yes, I'll plan to include an example in the next revision about using different URIs to trigger specific rate pacing policies in the dCDN.

Regarding the use case about differing rates based on the access network type - can someone clarify why a content provider might want to use a different rate on a mobile network vs a cable or fiber network? The rate pacing metadata is for the content provider to specify (via the uCDN) the rate at which content should be transmitted by the dCDN to the end client. The main use case we've had in mind is that the content provider wants to avoid being charged for bytes that were sent to the client but never consumed. It's not clear to me how access network type would play into this unless there's some other use case for rate pacing to be considered.

Thanks,
Matt 

> Sent: Tuesday, November 18, 2014 1:11 AM
> To: Matt Caulfield (mcaulfie)
> Cc: Francois Le Faucheur (flefauch); Ma Kevin; [email-masked]; Kent
> Leung (kleung); [email-masked]
> In any cases, I recommend that you add some text in the next rev
> capturing how the rate-pacing capability as currently described can be
> combined with the use of different URIs allocated by the portal to
> different requests, in order to achieve different rate-pacing rates (or
> different rate-pacing algorithms if/when addituional ones are specified)
> for different request profiles.
> You could also give the example of a scenario where different URIs (and
> therefore different rate-pacing rates) are applied to requests based on
> device types (as extracted from HTTP headers).
> 
> With respect to the initial usecase of applying different rate-pacing rates
> depending on different access networks, do you feel it is
> always/generally feasible to determine the access network based on
> information available in the initial content request, given many devices
> are capable of using various access types ?
> 
> Cheers
> 
> Francois
> 
> 
> >>>>> Hi Matt. Just wondering if this supports the case when uCDN
> wants
> >> the
> >>>>> URL:            http://www.ietf.org/internet-drafts/draft-caulfield-
> cdni-
> >>>>> rate-pacing-02.txt
> >>>>>  extensions for downstream CDNs to support rate pacing on
> behalf
> >> of
> >>>>>  upstream CDNs.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>

---

From: <[email-masked]>
Date: Wed, 19 Nov 2014 10:02:11 +0000

Matt,

mobile vs fixed networks may be paced with a different algorithm / rate as also mobile networks cost more to backhaul / operate so delivering bytes too quickly that are not used by the EU is wasteful, this is exacerbated by the usage profile of mobile end users consuming video, which is that they are less likely to watch an asset through to the end in 1 go vs a fixed line / set-top-box who would be more likely to. [citation needed] :)

Mobile networks are bandwidth constrained end-to-end and have higher jitter, which would also potentially lend itself to needing a different pacing algorithm than a fixed line to enable the operator to optimise and tune.

I don’t know of a reason right now why for the sub-types of "other" fixed access network we would want to set pacing algorithm / rate differently.

Mal

-----Original Message-----
From: Matt Caulfield (mcaulfie) [mailto:[email-masked]] 
Sent: 18 November 2014 21:08
To: Francois Le Faucheur (flefauch)
Cc: Ma Kevin; Hubert,MT,Mal,TAC3 R; Kent Leung (kleung); [email-masked]
Subject: RE: [CDNi] New Version Notification for draft-caulfield-cdni-rate-pacing-02.txt

Hi Francois,

Thanks,
Matt 

> different requests, in order to achieve different rate-pacing rates 
> (or different rate-pacing algorithms if/when addituional ones are 
> specified) for different request profiles.
> You could also give the example of a scenario where different URIs 
> (and therefore different rate-pacing rates) are applied to requests 
> based on device types (as extracted from HTTP headers).
> 
> With respect to the initial usecase of applying different rate-pacing 
> rates depending on different access networks, do you feel it is 
> information available in the initial content request, given many 
> devices are capable of using various access types ?
> 
> Cheers
> 
> Francois
> 
> 
> >> draft-caulfield-cdni- rate-pacing-02.txt
> >>
> >> Hi Mal,
> >>
> >>> draft-caulfield-cdni-
> >>> Certainly from a operators perspective, enabling rate pacing / 
> >>> setting
> >> the
> >>> algorith per footprint is more attractive than a binary mobile / 
> >>> non-
> >> mobile.
> >>> addition, setting the actual pacing value per content uri / 
> >>> content uri regex / content 'type' / content provider are also all 
> >>> valid. Not sure if that makes it a bit complication though!
> >>>
> >>> Regards
> >>>
> >>> Mal
> >>>
> >>> draft-caulfield-cdni-
> >>>>>  Rate pacing is a class of network traffic shaping which limits 
> >>>>> the  transmission rate of data over a network.  This document 
> >>>>> defines
> >> CDNI
> >>>>> Please note that it may take a couple of minutes from the time 
> >>>>> of submission until the htmlized version and diff are available 
> >>>>> at
> >>> tools.ietf.org.
> >>>>>
> >>>>> The IETF Secretariat
> >>>>>

---

From: "Matt Caulfield (mcaulfie)" <[email-masked]>
Date: Wed, 19 Nov 2014 15:29:17 +0000

Hi Mal,

Thanks for the response.

Yes - I can see why a mobile network operator might be concerned with having their own special rate pacing algorithm or implementation of an algorithm.

However, why does the content provider care? Under what scenario would a content provider find it beneficial to choose a different rate pacing metadata/algorithms/parameters for mobile vs fixed? As a CP, do I have some incentive to choose a rate pacing algorithm for mobile networks which is different than fixed line networks?

The draft gives some flexibility to the dCDN in terms of implementation. Whether the dCDN want to do some different traffic shaping (which still fits within the token bucket envelope) for mobile vs fixed line is an implementation detail of the dCDN. 

Matt

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, November 19, 2014 5:02 AM
> To: Matt Caulfield (mcaulfie); Francois Le Faucheur (flefauch)
> Cc: [email-masked]; Kent Leung (kleung); [email-masked]
> mobile vs fixed networks may be paced with a different algorithm / rate
> as also mobile networks cost more to backhaul / operate so delivering
> bytes too quickly that are not used by the EU is wasteful, this is
> exacerbated by the usage profile of mobile end users consuming video,
> which is that they are less likely to watch an asset through to the end in 1
> go vs a fixed line / set-top-box who would be more likely to. [citation
> needed] :)
> 
> Mobile networks are bandwidth constrained end-to-end and have
> higher jitter, which would also potentially lend itself to needing a
> different pacing algorithm than a fixed line to enable the operator to
> optimise and tune.
> 
> I don’t know of a reason right now why for the sub-types of "other"
> fixed access network we would want to set pacing algorithm / rate
> differently.
> 
> Mal
> 
> Yes, I'll plan to include an example in the next revision about using
> different URIs to trigger specific rate pacing policies in the dCDN.
> 
> Regarding the use case about differing rates based on the access
> network type - can someone clarify why a content provider might want
> to use a different rate on a mobile network vs a cable or fiber network?
> The rate pacing metadata is for the content provider to specify (via the
> uCDN) the rate at which content should be transmitted by the dCDN to
> the end client. The main use case we've had in mind is that the content
> provider wants to avoid being charged for bytes that were sent to the
> client but never consumed. It's not clear to me how access network type
> would play into this unless there's some other use case for rate pacing to
> be considered.
> 
> Thanks,
> Matt
> 
> > >>> determine which request comes on which type of access
> network);
> > or
> > >>>> On 10 Nov 2014, at 14:31, Kent Leung (kleung)
> <[email-masked]>
> > >> wrote:
> > >>>>
> > >>>>> This new version of the rate pacing draft incorporates
> comments
> > >> from
> > >>>>> has been successfully submitted by Matt Caulfield and posted
> to
> > >> the
> > >>>>> IETF repository.
> > >>>>>

---

From: <[email-masked]>
Date: Wed, 19 Nov 2014 16:04:22 +0000

Matt,

Yeah youre right, CPs really dont care about the granularity and specifics of the operators network. :)

Mal

-----Original Message-----
From: Matt Caulfield (mcaulfie) [mailto:[email-masked]] 
Sent: 19 November 2014 15:29
To: Hubert,MT,Mal,TAC3 R; Francois Le Faucheur (flefauch)
Cc: [email-masked]; Kent Leung (kleung); [email-masked]
Subject: RE: [CDNi] New Version Notification for draft-caulfield-cdni-rate-pacing-02.txt

Hi Mal,

Thanks for the response.

Matt

> mobile vs fixed networks may be paced with a different algorithm / 
> rate as also mobile networks cost more to backhaul / operate so 
> delivering bytes too quickly that are not used by the EU is wasteful, 
> this is exacerbated by the usage profile of mobile end users consuming 
> video, which is that they are less likely to watch an asset through to 
> the end in 1 go vs a fixed line / set-top-box who would be more likely 
> to. [citation needed] :)
> 
> Mobile networks are bandwidth constrained end-to-end and have higher 
> jitter, which would also potentially lend itself to needing a 
> the end client. The main use case we've had in mind is that the 
> content provider wants to avoid being charged for bytes that were sent 
> to the client but never consumed. It's not clear to me how access 
> network type would play into this unless there's some other use case 
> for rate pacing to be considered.
> 
> Thanks,
> Matt
> 
> > capturing how the rate-pacing capability as currently described can 
> > be combined with the use of different URIs allocated by the portal 
> > to different requests, in order to achieve different rate-pacing 
> > rates (or different rate-pacing algorithms if/when addituional ones 
> > are
> > With respect to the initial usecase of applying different 
> > rate-pacing rates depending on different access networks, do you 
> > feel it is always/generally feasible to determine the access network 
> > based on information available in the initial content request, given 
> > many devices are capable of using various access types ?
> >
> > Cheers
> >
> > Francois
> >
> >
> > > The content provider can redirect the client to the most 
> > > appropriate
> > URI for their device.
> > >
> > >>> content uri regex / content 'type' / content provider are also 
> > >>> all valid. Not sure if that makes it a bit complication though!
> > >>>
> > >>> Regards
> > >>>
> > >>> Mal
> > >>>
> > >>> different types of access network (and it would then be up to 
> > >>> the
> > >> dCDN to
> > >>>>>  Rate pacing is a class of network traffic shaping which 
> > >>>>> limits the  transmission rate of data over a network.  This 
> > >>>>> document defines
> > >> CDNI
> > >>>>> of submission until the htmlized version and diff are 
> > >>>>> available at
> > >>> tools.ietf.org.
> > >>>>>
> > >>>>> The IETF Secretariat
> > >>>>>

---

From: "Flinck, Hannu (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 19 Nov 2014 16:18:47 +0000

But maybe the CPs care about the charges occurring to their users? As well as the end user experience?
If so then paging becomes an issue especially over mobile networks.  

- Hannu 

-----Original Message-----
From: CDNi [mailto:[email-masked]] On Behalf Of ext [email-masked]
Sent: Wednesday, November 19, 2014 6:04 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [CDNi] New Version Notification for draft-caulfield-cdni-rate-pacing-02.txt

Matt,

Mal

-----Original Message-----
From: Matt Caulfield (mcaulfie) [mailto:[email-masked]] 
Sent: 19 November 2014 15:29
To: Hubert,MT,Mal,TAC3 R; Francois Le Faucheur (flefauch)
Cc: [email-masked]; Kent Leung (kleung); [email-masked]
Subject: RE: [CDNi] New Version Notification for draft-caulfield-cdni-rate-pacing-02.txt

Hi Mal,

Thanks for the response.

Matt

---

From: "Matt Caulfield (mcaulfie)" <[email-masked]>
Date: Wed, 19 Nov 2014 16:23:26 +0000

Agreed, it may be that the fixed line network has unlimited bandwidth for subscribers whereas the mobile network is capped or charges per MB. However, why wouldn't a content provider just enable rate pacing for all access network types? Is there a reason they may want to avoid it for fixed line while at the same time enabling or using a different algo with mobile?

> From: Flinck, Hannu (NSN - FI/Espoo) [mailto:[email-masked]]
> Sent: Wednesday, November 19, 2014 11:19 AM
> To: ext [email-masked]; Matt Caulfield (mcaulfie); Francois Le
> Faucheur (flefauch)
> Cc: [email-masked]
> Yes - I can see why a mobile network operator might be concerned with
> having their own special rate pacing algorithm or implementation of an
> algorithm.
> 
> However, why does the content provider care? Under what scenario
> would a content provider find it beneficial to choose a different rate
> pacing metadata/algorithms/parameters for mobile vs fixed? As a CP, do
> I have some incentive to choose a rate pacing algorithm for mobile
> networks which is different than fixed line networks?
> 
> The draft gives some flexibility to the dCDN in terms of implementation.
> Whether the dCDN want to do some different traffic shaping (which still
> fits within the token bucket envelope) for mobile vs fixed line is an
> implementation detail of the dCDN.
> 
> Matt
> 
> higher
> > > >>> We have use cases to rate pace on wired connected subscribers
> as
> > > >> well. In
> > > >>> From: CDNi [mailto:[email-masked]] On Behalf Of
> Francois
> > Le
> > > >> Faucheur
> > > >>> (flefauch)
> > > >>> 	(ii) to specifiy different rate-pacing control parameters
> for
> > > >>> different “footprints"
> > > >>>

---

From: "Flinck, Hannu (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 20 Nov 2014 16:36:26 +0000

I am not aware of any such reasons

best regards
Hannu

-----Original Message-----
From: ext Matt Caulfield (mcaulfie) [mailto:[email-masked]] 
Sent: Wednesday, November 19, 2014 6:23 PM
To: Flinck, Hannu (NSN - FI/Espoo); ext [email-masked]; Francois Le Faucheur (flefauch)
Cc: [email-masked]
Subject: RE: [CDNi] New Version Notification for draft-caulfield-cdni-rate-pacing-02.txt

> > > >> [email-masked]