You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficcontrol.apache.org by "Dremin, Sergey" <Se...@comcast.com> on 2018/06/06 20:50:39 UTC
Re: [EXTERNAL] Re: Add minimum caches field to deep routing logic
Hi Eric,
The problem will materialize once we enable deep routing for non-live delivery channels with larger libraries. Those delivery channels need to be deep routed only to deep cache groups of sufficient size to make sure caching efficiency remains at acceptable levels. Right now that is not possible. They will be routed to any deep cache groups, even where there is a single server, resulting in poor caching efficiency, and more traffic to the mids.
Does that explain the problem sufficiently?
~Sergey
On 6/5/18, 7:10 PM, "Eric Friedrich (efriedri)" <ef...@cisco.com> wrote:
Hey Sergey-
What is the problem that you are experiencing here?
I understand what you are proposing, but am not sure why this is needed. I would find some more details very useful
Thanks,
Eric
> On Jun 5, 2018, at 5:40 PM, Dremin, Sergey <Se...@comcast.com> wrote:
>
> We should create an extension to the deep caching/deep routing field that will allow you to specify a minimum # of caches in a deep cache group for that deep cache group to be enabled for that DS.
>
>
>
> Cache group size is proportional to caching efficiency. Having a configurable value for a minimum # of caches for a DS would allow to change the caching efficiency for that DS versus the routing efficiency (that comes with deep routing) for that DS.
>
>
>
> Ideally this is something that is set based on current CDN performance.
>
>
>
> 1. A deep routing enabled DS with poor caching efficiency could use a bigger minimum size for a deep cache group.
> 2. A deep routing enabled DS with not sufficient deep routing usage, could use a smaller minimum size for a deep cache group.
>
>
>
> Right now, we need to decide if we want to make this configurable or static. Since I think this will need to be configurable in the future anyway, so it a good idea to do it now.
>
>
>
> This will require changes to TO/TP and traffic router.
>
> Thoughts?
Re: [EXTERNAL] Add minimum caches field to deep routing logic
Posted by "Dremin, Sergey" <Se...@comcast.com>.
Eric, good points, thank you.
Have you considered using deep cache CG TB provisioned instead of # caches in group?
Not all caches are created equal- 5 caches in CG1 maybe have half the storage of 2 caches in CG2.
- No and true. I don't think I need this to be this complicated yet.
Does the state/availability of a cache impact TRs decision?
Is there a difference between a cache being REPORTED, REPORTED (and overloaded by TM), OFFLINE, ADMIN_DOWN?
- Yes, additional TR logic will be required to hand this properly.
On 6/8/18, 11:04 AM, "Eric Friedrich (efriedri)" <ef...@cisco.com> wrote:
Hey Sergey-
I’m good with it in general. A few design considerations:
Have you considered using deep cache CG TB provisioned instead of # caches in group?
Not all caches are created equal- 5 caches in CG1 maybe have half the storage of 2 caches in CG2.
Does the state/availability of a cache impact TRs decision?
Is there a difference between a cache being REPORTED, REPORTED (and overloaded by TM), OFFLINE, ADMIN_DOWN?
—Eric
> On Jun 8, 2018, at 12:41 PM, Dremin, Sergey <Se...@comcast.com> wrote:
>
> Unless people have more questions/opinions, can I assume we are happy with this new routing/caching efficiency knob?
> I don’t see how this could negatively affect anything, besides complicating DS configuration further.
>
> On 6/6/18, 2:50 PM, "Dremin, Sergey" <Se...@comcast.com> wrote:
>
> Hi Eric,
> The problem will materialize once we enable deep routing for non-live delivery channels with larger libraries. Those delivery channels need to be deep routed only to deep cache groups of sufficient size to make sure caching efficiency remains at acceptable levels. Right now that is not possible. They will be routed to any deep cache groups, even where there is a single server, resulting in poor caching efficiency, and more traffic to the mids.
> Does that explain the problem sufficiently?
> ~Sergey
>
>
> On 6/5/18, 7:10 PM, "Eric Friedrich (efriedri)" <ef...@cisco.com> wrote:
>
> Hey Sergey-
> What is the problem that you are experiencing here?
>
> I understand what you are proposing, but am not sure why this is needed. I would find some more details very useful
>
> Thanks,
> Eric
>
>
>
>
>> On Jun 5, 2018, at 5:40 PM, Dremin, Sergey <Se...@comcast.com> wrote:
>>
>> We should create an extension to the deep caching/deep routing field that will allow you to specify a minimum # of caches in a deep cache group for that deep cache group to be enabled for that DS.
>>
>>
>>
>> Cache group size is proportional to caching efficiency. Having a configurable value for a minimum # of caches for a DS would allow to change the caching efficiency for that DS versus the routing efficiency (that comes with deep routing) for that DS.
>>
>>
>>
>> Ideally this is something that is set based on current CDN performance.
>>
>>
>>
>> 1. A deep routing enabled DS with poor caching efficiency could use a bigger minimum size for a deep cache group.
>> 2. A deep routing enabled DS with not sufficient deep routing usage, could use a smaller minimum size for a deep cache group.
>>
>>
>>
>> Right now, we need to decide if we want to make this configurable or static. Since I think this will need to be configurable in the future anyway, so it a good idea to do it now.
>>
>>
>>
>> This will require changes to TO/TP and traffic router.
>>
>> Thoughts?
>
>
>
>
>
Re: [EXTERNAL] Add minimum caches field to deep routing logic
Posted by "Eric Friedrich (efriedri)" <ef...@cisco.com>.
Hey Sergey-
I’m good with it in general. A few design considerations:
Have you considered using deep cache CG TB provisioned instead of # caches in group?
Not all caches are created equal- 5 caches in CG1 maybe have half the storage of 2 caches in CG2.
Does the state/availability of a cache impact TRs decision?
Is there a difference between a cache being REPORTED, REPORTED (and overloaded by TM), OFFLINE, ADMIN_DOWN?
—Eric
> On Jun 8, 2018, at 12:41 PM, Dremin, Sergey <Se...@comcast.com> wrote:
>
> Unless people have more questions/opinions, can I assume we are happy with this new routing/caching efficiency knob?
> I don’t see how this could negatively affect anything, besides complicating DS configuration further.
>
> On 6/6/18, 2:50 PM, "Dremin, Sergey" <Se...@comcast.com> wrote:
>
> Hi Eric,
> The problem will materialize once we enable deep routing for non-live delivery channels with larger libraries. Those delivery channels need to be deep routed only to deep cache groups of sufficient size to make sure caching efficiency remains at acceptable levels. Right now that is not possible. They will be routed to any deep cache groups, even where there is a single server, resulting in poor caching efficiency, and more traffic to the mids.
> Does that explain the problem sufficiently?
> ~Sergey
>
>
> On 6/5/18, 7:10 PM, "Eric Friedrich (efriedri)" <ef...@cisco.com> wrote:
>
> Hey Sergey-
> What is the problem that you are experiencing here?
>
> I understand what you are proposing, but am not sure why this is needed. I would find some more details very useful
>
> Thanks,
> Eric
>
>
>
>
>> On Jun 5, 2018, at 5:40 PM, Dremin, Sergey <Se...@comcast.com> wrote:
>>
>> We should create an extension to the deep caching/deep routing field that will allow you to specify a minimum # of caches in a deep cache group for that deep cache group to be enabled for that DS.
>>
>>
>>
>> Cache group size is proportional to caching efficiency. Having a configurable value for a minimum # of caches for a DS would allow to change the caching efficiency for that DS versus the routing efficiency (that comes with deep routing) for that DS.
>>
>>
>>
>> Ideally this is something that is set based on current CDN performance.
>>
>>
>>
>> 1. A deep routing enabled DS with poor caching efficiency could use a bigger minimum size for a deep cache group.
>> 2. A deep routing enabled DS with not sufficient deep routing usage, could use a smaller minimum size for a deep cache group.
>>
>>
>>
>> Right now, we need to decide if we want to make this configurable or static. Since I think this will need to be configurable in the future anyway, so it a good idea to do it now.
>>
>>
>>
>> This will require changes to TO/TP and traffic router.
>>
>> Thoughts?
>
>
>
>
>
Re: [EXTERNAL] Re: Add minimum caches field to deep routing logic
Posted by "Dremin, Sergey" <Se...@comcast.com>.
Unless people have more questions/opinions, can I assume we are happy with this new routing/caching efficiency knob?
I don’t see how this could negatively affect anything, besides complicating DS configuration further.
On 6/6/18, 2:50 PM, "Dremin, Sergey" <Se...@comcast.com> wrote:
Hi Eric,
The problem will materialize once we enable deep routing for non-live delivery channels with larger libraries. Those delivery channels need to be deep routed only to deep cache groups of sufficient size to make sure caching efficiency remains at acceptable levels. Right now that is not possible. They will be routed to any deep cache groups, even where there is a single server, resulting in poor caching efficiency, and more traffic to the mids.
Does that explain the problem sufficiently?
~Sergey
On 6/5/18, 7:10 PM, "Eric Friedrich (efriedri)" <ef...@cisco.com> wrote:
Hey Sergey-
What is the problem that you are experiencing here?
I understand what you are proposing, but am not sure why this is needed. I would find some more details very useful
Thanks,
Eric
> On Jun 5, 2018, at 5:40 PM, Dremin, Sergey <Se...@comcast.com> wrote:
>
> We should create an extension to the deep caching/deep routing field that will allow you to specify a minimum # of caches in a deep cache group for that deep cache group to be enabled for that DS.
>
>
>
> Cache group size is proportional to caching efficiency. Having a configurable value for a minimum # of caches for a DS would allow to change the caching efficiency for that DS versus the routing efficiency (that comes with deep routing) for that DS.
>
>
>
> Ideally this is something that is set based on current CDN performance.
>
>
>
> 1. A deep routing enabled DS with poor caching efficiency could use a bigger minimum size for a deep cache group.
> 2. A deep routing enabled DS with not sufficient deep routing usage, could use a smaller minimum size for a deep cache group.
>
>
>
> Right now, we need to decide if we want to make this configurable or static. Since I think this will need to be configurable in the future anyway, so it a good idea to do it now.
>
>
>
> This will require changes to TO/TP and traffic router.
>
> Thoughts?