[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Recursion vs Redirection
Considering that we are dealing with proxies, I don't think that state
should be a problem 8-) However, it is this state maching that in fact
becomes extremely valuable; otherwise, if my peered CDN request routing
system fails, I have no knowledge of it unless I periodically poll
them...based upon your polling interval, this could be a considerable
amount of delay. In addition, the peered request routing system may be
available to you but not routable by the client...an on, and on, ad
nauseum... I've experienced a bit of trepidation from content provider,
CDN operators and the likes when they understand that we throw the content
delivery "over the wall" to a peered network without any control other
than a second chance when a TTL expires.
On Mon, 15 Oct 2001, Oliver Spatscheck wrote:
> the only problem with a recursive approach is that it requires changes
> to the existing infrastructure and adds additional overhead to the CDN
> receiving the inital request (For example, if a flash crowed arrives
> the CDN receiving the inital request has to track all the state of the
> outstanding requests to other CDNs etc..). As pointed out before I
> think whatever protocols we come up with should support both.
> Eric Dean writes:
> > A few months ago, I mentioned the concept of using a recursive DNS query
> > for CDI rather than CNAMEs. CNAMEs create problems whereby a peered CDN
> > experiencing QoS problems can adversely affect content requests until a
> > TTL expiration occurs. This can create apprehension when a CDN operator
> > does not have strict control of a publisher's content.
> > However, CDI via recursive DNS queries that transpose the client's IP
> > address into the additional section preserves all CDN request routing
> > information while providing a different level of administrative control.
> > Eric Dean
> > President, Crystal Ball Inc.
> > W 703-322-8000
> > F 703-322-8010
> > M 703-597-6921
President, Crystal Ball Inc.