Re: [DNSOP] Ask for advice of 3 new RRs for precise traffic scheduling

[左鹏 <[e-mail]>]

thanks for your comment!

> -----原始邮件-----
> 发件人: "Robert Edmonds" <[e-mail]>
> 发送时间: 2017-12-15 05:40:56 (星期五)
> 收件人: "bert hubert" <[e-mail]>
> 抄送: "[e-mail]" <[e-mail]>, dnsop <[e-mail]>
> 主题: Re: [DNSOP] Ask for advice of 3 new RRs for precise traffic scheduling
> 
> bert hubert wrote:
> > On Wed, Dec 13, 2017 at 05:36:32PM +0800, [e-mail] wrote:
> > >  so far as i know, many CDNs already use similar methods as you mentioned in PowerDNS 4.1.1 
> > >  but  i think only the  Authoritative Server change is not enough,  support on the recursive server is also very important .
> > >   because the resolver determines the reponse to clients.
> > 
> > This is true.  A typical resolver will serve around 50,000 to 2,000,000
> > users (although this is rare). This means that for 60 seconds, you shift
> > around 'a hundred thousand' potential users. 
> > 
> > In practice, this appears to be good enough from what I hear.
> > 
> > Or let me put it another way, before we burden the DNS protocol with another
> > record type we have to add downgrade/workaround/DNSSEC support for, we
> > should have numbers that say it solves a problem.
> > 
> > CDNs could maybe chime in.
> 
> Hi,
> 
> With my CDN hat on, I don't see any need to turn over scheduling
> decisions to resolvers. Extremely precise amounts of traffic can already
> be scheduled to individual CDN nodes because you have a large pool of
> owner names to work with, not a single owner name, and every (QNAME,
> QTYPE, resolver IP, client subnet [if present], anycast location that
> receives the query) tuple is an opportunity to make a unique scheduling
> choice. Generally, however, assignments to CDN nodes should be
> relatively sticky. You want to be shifting traffic for performance
> reasons, not capacity reasons.
> 

The "precise traffice scheduling" i mentioned is not only for performance reason, but also for capacity reason.
For performance, i think the existing system already works fine. As long as a CDN DNS has "view" function, the local DNS can 
bring the client to the closest CDN nodes easily.  
For capacity, here is a user case. I learned this case from people working in a CDN company,though i am not sure if it is a 
common problem worldwide. For example, a CDN provider has 10G capacity in province A and 8G in province B. (B is close to A 
geographically).  For some reason(eg. large population in A), 10G is not enough in the rush hour. Assume there is 12G trafffic during rush hour, the CDN needs to schedule 2G to province B while keep 10G in A.  


> Or, put another way, we like existing resolver implementations just
> fine, we just wish there were a lot more resolver instances, and closer
> to clients :-)
> 

yes, more resolvers are good to improve user experience.
but also maybe we should notice each CDN node has different capacity.(it is the real in practice).
a "weight-aware" rosolver can schedule clients to diffent nodes according to weight pricisely.
or shall we do something only for authoritative server like defining the weighted A/AAAAx? 

btw, any comments on the weightd CNAMEXs for multi-CDN? :)
> -- 
> Robert Edmonds