Re: Verifying, identifying and ack-ing requests ....

["Hilarie Orman" <HORMAN@novell.com>]

Just a thought on the possible requirements ...

If, in practice, CDN-A's are very interested in the status of redirections
and request receipts, etc., then I'd guess that if the CDN protocols don't
support the information exchange, then all sorts of bizarre cookie
hacks and anti-cookie hacks will be employed.  So, if anyone has
strong requirements at this stage for stronger notions of reliability
in delegated protocol operations, it might lead to greater
architectural simplicity to address them now rather than later.

Hilarie

>>> Oliver Spatscheck <spatsch@research.att.com> 01/20/01 04:12PM >>>
Abhi Deshmukh writes:
 > I have a set of questions on Identification, Verification and
 > Acknowledgement of requests, that would help me understand the current or
 > proposed working of peered CDNs. Here goes.
 > 
 > Assume that CDN-A and CDN-B peer with each other. 
 > Assume that CDN-A forwards an end-user request R to CDN-B.
 > 
 > 0. How does CDN-A know that CDN-B has succesfully (or un-successfully) 
 > received the request R ?

I don't think it is a requirement for CDN-A to know this. If for example DNS
based redirection is used CDN-A will never know if a end-user got a response
(with or without CDN peering). So we don't make things worse in that case.

On the other hand CDN-A is most likely interested in knowing if CDN-B
fulfills its SLA (might guarantee a 99.999% redirection success rate),
however, I thought that we wanted to keep SLA enforcement outside
the scope of this working group.

 > 
 > 1. How does CDN-A know that CDN-B has succesfully (or un-successfully) 
 > serviced the request R ?
 > 

I think one important aspect here is that one redirection might result in many
serviced requests. So we have R which is a request routing request ( for
example, DNS resolution) and S which is a service request (for example, HTTP
GET) and in general there is a one to many mapping between R and S. I also
think my comments to 0. apply here.

 > 2. Does CDN-B send a real-time or batched response back to CDN-A after the
 > request R is serviced ?
 > 

As pointed out in the request routing requirements draft we will need
some aggregated pseudo real time feedback. However, I feel the actual
detailed logs can be batched.

 > 3. How does CDN-A verify the work (including QoS, SLA, etc) done by CDN-B
 > while trying to service request R ?  
 > 	3.a  Do CDN-A and CDN-B share common/neutral monitoring apps at each
 > service points ?
 > 

See comments above. Is the verification part of our requirements? I would
like to know how other people think about this.

 > 4. Is each request between CDN-A and CDN-B identified uniquely ? Is it as
 > simple as a combination of timestamp and a rolling counter ?
 > 

The request routing request or the service request?


Oliver