[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Verifying, identifying and ack-ing requests ....
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.
> -----Original Message-----
> From: Hilarie Orman [mailto:HORMAN@novell.com]
> Sent: Monday, January 22, 2001 12:34 PM
> To: email@example.com
> Cc: firstname.lastname@example.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
> 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.
> >>> Oliver Spatscheck <email@example.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
> > 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
> > 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?