Subject: [CDNi] TR: New (-01) version of CDNI Use Cases drafts

From: <[email-masked]>
Date: Wed, 2 Feb 2011 18:07:26 +0100

Hi Ben,

Thanks for your feedback. Please see my comments inline.

Best regards,

--

Gilles

 

-----Message d'origine-----

De : Ben Niven-Jenkins [mailto:[email-masked]] Envoyé : lundi 31 

janvier 2011 18:38 À : BERTRAND Gilles RD-CORE-ISS; [email-masked] 

Objet : Re: [CDNi] New (-01) version of CDNI Use Cases drafts

(...)

"2.2.2.   Resiliency

...

Resiliency may also be required against failure to ingest content

from the CSP.  In these cases the content may be available from

another CDSP."

I think it would be useful if you could try and expand on the part 

of the resiliency use case related to failures like this as I 

suspect there may be some additional requirements hiding under the surface.

For example, is there an assumption that the downstream CDN already 

has the content, or is there an assumption that the failure that 

meant the upstream CDN could not ingest the content does not impact 

the downstream CDN's ability to ingest from the same CSP?

[ GILLES: 

If the CSP uses some protection 

mechanism to allow the content ingestion, there could be situations 

where the upstream CDN successfully ingests the content (the CSP authorizes the ingestion request), whereas the 

CSP rejects direct ingestion requests from the downstream CDN. To circumvent the problem, the dCDN might ingest content through the uCDN. ]

"3.2.  Gaps in Existing Solutions and Need for Specifications"

This section mentions three limitations that were discovered during 

your experiments, I wonder whether they were knock-on effects of 

those initial limitations that it would be worthwhile to describe, 

for example (and this is a made up example) having to define target 

URLs manually between CDNs may have meant that some common CDN 

features like token/url authorisation could not be used. Describing 

such knock-on effects would be useful as we can ensure the CDNI 

solution addresses those as well as the first order requirements.

(Of course you may not want to reveal all the details of the 

limitations your experiments found and if that's the case, that's OK 

with me but you should still try to ensure the requirements document 

adequately covers those use cases)."

[GILLES: 

The limitations list in this section of the I-D is non exhaustive. We are 

preparing an I-D, which will describe our experiments and identified limitations more in details. 

We will for sure try to ensure that the requirements draft covers the identified issues.]

---

From: Benjamin Niven-Jenkins <[email-masked]>
Date: Sun, 6 Feb 2011 11:38:57 +0000

Gilles,

See inline below:

> CSP rejects direct ingestion requests from the downstream CDN. To circumvent the problem, the dCDN might ingest content through the uCDN. ]

OK I understand. I think this is already covered in the requirements draft.

> We will for sure try to ensure that the requirements draft covers the identified issues.]

Great. I very much look forward to reading the draft when it is available.

Ben