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

[DonE@activate.net]

I agree that real-time verification is not important.
Verification is important, but it is done by logs at
accounting-time, and that data can be verified by a
third party like Keynote.

Don

> -----Original Message-----
> From: Hilarie Orman [mailto:HORMAN@novell.com]
> Sent: Monday, January 22, 2001 12:34 PM
> To: spatsch@research.att.com
> Cc: cdn@ops.ietf.org
> Subject: Re: Verifying, identifying and ack-ing requests ....
> 
> 
> 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
> 
> 
>