Subject: [CDNi] draft-ietf-cdni-cases-00

From: Alan Kavanagh <[email-masked]>
Date: Thu, 3 Nov 2011 18:08:13 -0400

Hi Authors

A couple of questions and suggestions in relation to the current cdni-use-cases-00 draft. Hope these comments/suggestions helps improve the draft. I also have some questions noted below.

 *   Section 1.1. You mention Access CDN. Is this more an operator own and managed CDN in the Access Domain that may have access to end user information or are you talking about a given Access CDN having access to the end-users profile, im assuming its the former but felt its not clear in the draft.
 *   Section 1.3. First bullet " improve the experience for the End User; for instance delivery has
      lower latency and better robustness". Suggest to add and reduce Round Trip Time as content is positioned closer to end user.
 *   Section 1.3. Third bullet mentions reduced electricity consumption, could you expand on that and say how this is achieved?
 *   Section 1.3. Suggest to add CSP-3 in Figure-1 to be consistent.
 *   Section 1.4. I understand what you are conveying here, makes sense. I would however clarify that CDN's even external ones to interconnect with others today but use a Proprietary interface to do so etc.
 *   Section 2.3. Is their enough movement of nomadic users are moving to cache content in the first place?....im thinking here than you may be nomadic but also geo-blocked, believe that should be very clearly clarified.
 *   Section 3.1. "However, unexpected spikes in content popularity may drive load...." suggest to "flash crowds" after content popularity.
 *   Section 3.1 Offloading. It should be noted that this use case would require knowledge about the other CDN to know if the other CDN has the resources to offload the requests in the first place and also if the content is available in the CDN being offloaded too.
 *   Section 4.1. Im having difficulty in seeing how number 1 is a typical CDN use case of today? IMHO i dont not agree that its a typical model.
 *   Section 4.1. example 2. "the ability to deliver content over a protocol that is required by specific mobile devices and not supported by CDN-A." Can you give some examples on this as im having a hard time seeing this in reality?
 *   Section 10. Shouldn't it also cover a section on Authorization to view content and Authorization with Origin Server?

Best Regards
Alan

---

From: <[email-masked]>
Date: Mon, 7 Nov 2011 11:19:00 +0100

Hi Alan,

Thanks for your review of the I-D. I added my answers in line.

*	Section 1.1. You mention Access CDN. Is this more an operator
own and managed CDN in the Access Domain that may have access to end
user information or are you talking about a given Access CDN having
access to the end-users profile, im assuming its the former but felt its
not clear in the draft. 

I did not understand your question. Could you please rephrase? Thanks. 

*	Section 1.3. First bullet " improve the experience for the End
User; for instance delivery has
	      lower latency and better robustness". Suggest to add and
reduce Round Trip Time as content is positioned closer to end user.

By lower latency, we mean decrease the round trip time between the user
and the delivery server. 

*	Section 1.3. Third bullet mentions reduced electricity
consumption, could you expand on that and say how this is achieved?

Popular content is delivered through the CDN rather than through the
content provider's servers. Therefore, the content providers'
infrastructure can be smaller (less servers etc).

To be consistent with what?

*	Section 1.4. I understand what you are conveying here, makes
sense. I would however clarify that CDN's even external ones to
interconnect with others today but use a Proprietary interface to do so
etc.

Do you know examples of production CDNs interconnected through
proprietary interfaces today?

*	Section 2.3. Is their enough movement of nomadic users are
moving to cache content in the first place?....im thinking here than you
may be nomadic but also geo-blocked, believe that should be very clearly
clarified.

We will clarify this section in the next version of the I-D.

*	Section 3.1. "However, unexpected spikes in content popularity
may drive load...." suggest to "flash crowds" after content popularity.

ok

*	Section 3.1 Offloading. It should be noted that this use case
would require knowledge about the other CDN to know if the other CDN has
the resources to offload the requests in the first place and also if the
content is available in the CDN being offloaded too.

I agree: the CDN on which requests are offloaded must be able to handle
the offloaded requests. This introduces requirements on the metadata
(and control) interfaces.

*	Section 4.1. Im having difficulty in seeing how number 1 is a
typical CDN use case of today? IMHO i dont not agree that its a typical
model.

We do not assert that it is a typical CDN use case today. It is rather
one of the cases where CDNI would be useful. 

*	Section 10. Shouldn't it also cover a section on Authorization
to view content and Authorization with Origin Server?

Yes it would be interesting to mention these issues. We will extend this
section in the next version of the I-D.

Best regards,

Gilles

---

From: Alan Kavanagh <[email-masked]>
Date: Mon, 14 Nov 2011 16:55:57 -0500

Hi Gilles

Responses inline below.

Alan

________________________________
From: [email-masked] [mailto:[email-masked]]
Sent: November-07-11 5:19 AM
To: Alan Kavanagh; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: draft-ietf-cdni-cases-00

Hi Alan,

 *   Section 1.1. You mention Access CDN. Is this more an operator own and managed CDN in the Access Domain that may have access to end user information or are you talking about a given Access CDN having access to the end-users profile, im assuming its the former but felt its not clear in the draft.
I did not understand your question. Could you please rephrase? Thanks.
A.K.--> my point here is that you tying Access CDN with end users profile information such as given subscriber profile information an Access Network Provider has such as data line rate etc. So my point was are you stating the Access CDN has an i/f to sub mgmt that Access Network Provider knows?

 *   Section 1.3. First bullet " improve the experience for the End User; for instance delivery has
      lower latency and better robustness". Suggest to add and reduce Round Trip Time as content is positioned closer to end user.
By lower latency, we mean decrease the round trip time between the user and the delivery server.
A.K.--> yes my point exactly, just needs to be reworded in the draft for easier reading.

 *   Section 1.3. Third bullet mentions reduced electricity consumption, could you expand on that and say how this is achieved?
Popular content is delivered through the CDN rather than through the content provider's servers. Therefore, the content providers' infrastructure can be smaller (less servers etc).
A.K.--> I think that example should be noted in the draft such that caching reduces transport in certain network segments which may in turn imply reduce electric consumption etc.

 *   Section 1.3. Suggest to add CSP-3 in Figure-1 to be consistent.
To be consistent with what?
A.K.--> Reading section 1.3 last paragraph you give another example of a "CSP-3", but CSP-3 is not shown in figure 1, so makes sense to add CSP-3 to Figure-1.

 *   Section 1.4. I understand what you are conveying here, makes sense. I would however clarify that CDN's even external ones to interconnect with others today but use a Proprietary interface to do so etc.
Do you know examples of production CDNs interconnected through proprietary interfaces today?
A.K.--> Yes, lots of them :-). If you like i can craft some text to add to this section of use cases and my main point is to convey what is in the current market place to give a better reflection of the current technology landscape and market place, so im sure this is simple to add, but if you need me ill provide the text.

 *   Section 2.3. Is their enough movement of nomadic users are moving to cache content in the first place?....im thinking here than you may be nomadic but also geo-blocked, believe that should be very clearly clarified.
We will clarify this section in the next version of the I-D.
A.K.--> Cheers Gilles, look forward to that, if you need some examples etc just ping me.

 *   Section 3.1 Offloading. It should be noted that this use case would require knowledge about the other CDN to know if the other CDN has the resources to offload the requests in the first place and also if the content is available in the CDN being offloaded too.
I agree: the CDN on which requests are offloaded must be able to handle the offloaded requests. This introduces requirements on the metadata (and control) interfaces.
A.K.--> Yes, my point exactly, it would be useful to point that out in your draft to make it complete and also have it noted in the "CDNI Requirements Draft" .

 *   Section 4.1. Im having difficulty in seeing how number 1 is a typical CDN use case of today? IMHO i dont not agree that its a typical model.
We do not assert that it is a typical CDN use case today. It is rather one of the cases where CDNI would be useful.
A.K.--> Agree, though it might be useful to describe a "typical CDN usecase deployed today" which should be inserted into the draft. What we dont want to misrepresent is how its working today ;-)

 *   Section 10. Shouldn't it also cover a section on Authorization to view content and Authorization with Origin Server?
Yes it would be interesting to mention these issues. We will extend this section in the next version of the I-D.

A.K.--> cheers Gilles, i think that would really help complete the draft and help us in ensuring we tackel these issues in the relevant drafts etc.

Best regards,

Gilles

---

From: <[email-masked]>
Date: Tue, 15 Nov 2011 06:02:10 +0100

Hi Kent,

As raised by Alan in his e-mail below, in an offload use case the uCDN
would require information on the dCDNs to be aware of the amount of
traffic it can offload to every dCDN. I think this requirement is
already covered through the request routing interface as REQ-2 includes
the advertising of information about dCDN resources. Maybe we might add
a few words to REQ-2 to mention explicitly that resource information
could be needed for offload situations. 

I am not 100% clear today if the offload use case introduces specific
requirements on other interfaces (e.g., control and metadata) in
addition to the request routing interface. I see some specificity in
this use case, for instance, the duration during which the uCDN will use
the dCDN resources can be short in an offload situation (e.g., duration
of a flash crowd) as compared to a footprint extension use case.

Best regards,

Gilles

From: [email-masked] [mailto:[email-masked]] 
Sent: November-07-11 5:19 AM
To: Alan Kavanagh; [email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: RE: draft-ietf-cdni-cases-00

(...)

Section 3.1 Offloading. It should be noted that this use case would
require knowledge about the other CDN to know if the other CDN has the
resources to offload the requests in the first place and also if the
content is available in the CDN being offloaded too.

I agree: the CDN on which requests are offloaded must be able to handle
the offloaded requests. This (may)  introduce requirements on the
metadata (and control) interfaces. 

A.K.--> Yes, my point exactly, it would be useful to point that out in
your draft to make it complete and also have it noted in the "CDNI
Requirements Draft" .

(...)

(...)

---

From: <[email-masked]>
Date: Tue, 15 Nov 2011 06:09:41 +0100

Hi Alan

Thanks for your feedback. Please see my answers inline.

if you attend IETF#82 physically, I'll be happy to meet you to discuss any remaining issue.

Cheers,

Gilles

De : Alan Kavanagh [mailto:[email-masked]] 
Envoyé : mardi 15 novembre 2011 05:56
À : BERTRAND Gilles RD-CORE-ISS; STEPHAN Emile RD-CORE-LAN; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc : [email-masked]
Objet : RE: draft-ietf-cdni-cases-00

Hi Gilles

Responses inline below.

Alan

(...)

Gilles: The definition of an access CDN is intended to be a bit more generic than this. Through this definition we want to reflect the fact that a CDN connected to the end-user's access might have specific information that could help in providing a better delivery service. You provide relevant example of such information in your answer above. 

Gilles: OK, I have added a few words to clarify

Gilles: OK, I have added a few words to clarify

Gilles: thanks for the clarification. I have done the modification, it will appear in the next version of the I-D.

Gilles: I am aware of many lab tests/trials/etc for CDN interconnection. But today, I know very few examples of production CDNs interconnected through proprietary interfaces. So I am quite interested by the numerous examples you mention J. 

(...)

Gilles: OK I have added a sentence and forwarded your remark to Kent.

(...)

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Tue, 15 Nov 2011 00:52:17 -0800

Hi Gilles.  I'm not sure if the requirements should be written
explicitly to map to use cases unless the functions are for that purpose
only.  In this case, there could be numerous reasons why dCDN provides
its resource information to the uCDN.

The discussion below indicates a need for RRI requirement, which can be
traced to REQ-2.  Is this not sufficient?

Kent

From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, November 15, 2011 1:02 PM
To: Kent Leung (kleung)
Cc: [email-masked]; [email-masked]
Subject: RE: draft-ietf-cdni-cases-00

Hi Kent,

Best regards,

Gilles

(...)

(...)

(...)

---

From: <[email-masked]>
Date: Tue, 15 Nov 2011 10:02:16 +0100

Hi Kent,

Please see my answer below.

Gilles

De : Kent Leung (kleung) [mailto:[email-masked]] 
Envoyé : mardi 15 novembre 2011 16:52
À : BERTRAND Gilles RD-CORE-ISS
Cc : [email-masked]; [email-masked]
Objet : RE: draft-ietf-cdni-cases-00

Hi Gilles.  I'm not sure if the requirements should be written explicitly to map to use cases unless the functions are for that purpose only.  In this case, there could be numerous reasons why dCDN provides its resource information to the uCDN.

Gilles: I agree

The discussion below indicates a need for RRI requirement, which can be traced to REQ-2.  Is this not sufficient?

Gilles: I think it's sufficient indeed.

Kent

Hi Kent,

As raised by Alan in his e-mail below, in an offload use case the uCDN would require information on the dCDNs to be aware of the amount of traffic it can offload to every dCDN. I think this requirement is already covered through the request routing interface as REQ-2 includes the advertising of information about dCDN resources. Maybe we might add a few words to REQ-2 to mention explicitly that resource information could be needed for offload situations. 

I am not 100% clear today if the offload use case introduces specific requirements on other interfaces (e.g., control and metadata) in addition to the request routing interface. I see some specificity in this use case, for instance, the duration during which the uCDN will use the dCDN resources can be short in an offload situation (e.g., duration of a flash crowd) as compared to a footprint extension use case.

Best regards,

Gilles

(...)

Section 3.1 Offloading. It should be noted that this use case would require knowledge about the other CDN to know if the other CDN has the resources to offload the requests in the first place and also if the content is available in the CDN being offloaded too.

I agree: the CDN on which requests are offloaded must be able to handle the offloaded requests. This (may)  introduce requirements on the metadata (and control) interfaces. 

(...)

(...)

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 15 Nov 2011 09:35:03 +0000

> As raised by Alan in his e-mail below, in an offload use case the uCDN would require information on the dCDNs to be aware of the amount of traffic it can offload to every dCDN. I think this require…

This might not be what you meant (and if that's the case I apologise and just ignore me) but I'm not convinced that the uCDN needs to know how much capacity the dCDN has available. Instead it just needs to know if the dCDN is prepared "to do more work" on behalf of the uCDN.

Ben

> To: Alan Kavanagh; [email-masked]; [email-masked];[email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]
> (…)
> (…)
> (…)
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni

---

From: Alan Kavanagh <[email-masked]>
Date: Tue, 15 Nov 2011 19:56:48 -0500

Hi Kent

What might be useful is to jut capture the requirement somewhere as i believe their will be numerous ways to address the overload case and i can see changes required not just on CDN-I metadata i/f as GIlles is pointing out too, so for now lets capture the requirement.

Alan

________________________________
From: Kent Leung (kleung) [mailto:[email-masked]]
Sent: November-15-11 3:52 AM
To: [email-masked]
Cc: Alan Kavanagh; [email-masked]
Subject: RE: draft-ietf-cdni-cases-00

Kent

Hi Kent,

Best regards,

Gilles

________________________________
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: November-07-11 5:19 AM
To: Alan Kavanagh; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: draft-ietf-cdni-cases-00
(...)

(...)

---

From: "Lee, Yiu" <[email-masked]>
Date: Wed, 16 Nov 2011 02:02:22 +0000

Hi Alan,

I struggle how explicit we need to put in the requirement. Do you think a sub-bullet like: "information to signal overload to uCDN" is sufficient? Can you suggest some text which you think REQ-2 doesn't capture? We would like people to discuss the new text in the ML.

Thanks,
Yiu

From: Alan Kavanagh <[email-masked]<mailto:[email-masked]>>
Date: Tue, 15 Nov 2011 19:56:48 -0500
To: "Kent Leung (kleung)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [CDNi] draft-ietf-cdni-cases-00

Hi Kent

Alan

________________________________
From: Kent Leung (kleung) [mailto:[email-masked]]
Sent: November-15-11 3:52 AM
To: [email-masked]<mailto:[email-masked]>
Cc: Alan Kavanagh; [email-masked]<mailto:[email-masked]>
Subject: RE: draft-ietf-cdni-cases-00

Hi Gilles.  I’m not sure if the requirements should be written explicitly to map to use cases unless the functions are for that purpose only.  In this case, there could be numerous reasons why dCDN provides its resource information to the uCDN.

Kent

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, November 15, 2011 1:02 PM
To: Kent Leung (kleung)
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: draft-ietf-cdni-cases-00

Hi Kent,

Best regards,

Gilles

(…)
_______________________________________________ CDNi mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/cdni

---

From: Alan Kavanagh <[email-masked]>
Date: Tue, 15 Nov 2011 21:15:55 -0500

Hi Yiu

I never said it has to be explicit, then again capturing in the Requirements document suffices :-)

Sure here is some text it just needs to be captured. " dCDN Should inform the uCDN it can not handle any requests at this time", I dont think it needs to be noted as to why at a given instance of time the request can not be handled, if others feel different i would like to hear why. My only further comment is the oposite, i.e. to inform the uCDN when it can handle requests again.

BR
Alan

________________________________
From: Lee, Yiu [mailto:[email-masked]]
Sent: November-15-11 9:02 PM
To: Alan Kavanagh; Kent Leung (kleung); [email-masked]
Cc: [email-masked]
Subject: Re: [CDNi] draft-ietf-cdni-cases-00

Hi Alan,

Thanks,
Yiu

Hi Kent

Alan

---

From: Alan Kavanagh <[email-masked]>
Date: Tue, 15 Nov 2011 21:43:52 -0500

Sure, I don't believe you need to send that info, as that can cause other problems I can forsee. What makes more sense as I just hinted is to just say you CAN-NOT server this request and that is all. I fully agree you don't need to disclose any detailed information, my view is its just a yes I can serve or no I cant serve at this given time.

Alan 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
Sent: November-15-11 4:35 AM
To: [email-masked]
Cc: [email-masked]
Subject: [CDNi] dCDN capacity & offload (Re: draft-ietf-cdni-cases-00)

Ben

> To: Alan Kavanagh; [email-masked]; 
> [email-masked];[email-masked]; [email-masked];

---

From: Scott Wainner <[email-masked]>
Date: Wed, 16 Nov 2011 08:15:56 -0500

I presume we're talking about a binary decision (CAN SERVE / CANNOT 
SERVE) for a given class of services.

I also presume that the uCDN has made a decision that this particular 
dCDN is the right CDN to deliver the content (because the dCDN said it 
CAN SERVE and the uCDN determined that dCDN was the best choice).  We're 
not talking about isolated overload situations within the dCDN.  Given 
the uCDN has determined that the dCDN CAN SERVE, that dCDN must serve 
the content even if the dCDN cannot serve it from the most efficient 
location within the dCDN.

I would also think that the uCDN will dampen the loading to prevent a 
scenario where the following happens:

1) dCDN CAN SERVE
2) uCDN loads up the dCDN up
3) dCDN CANNOT SERVE because of the loading from uCDN
4) uCDN off-loads that dCDN
5) return to 1

Is there merit in adding another condition advertised by the dCDN that 
the uCDN can use in the evaluation criteria (e.g. CANNOT SERVE, 
OFF-LOAD, CAN SERVE).  The dCDN can determine under what conditions it 
wants to OFF-LOAD that class of traffic (internal threshold, internal 
network fault, maintenance, etc.).

Scott

On 11/15/11 9:43 PM, Alan Kavanagh wrote:
>
> Sure, I don't believe you need to send that info, as that can cause 
> other problems I can forsee. What makes more sense as I just hinted is 
> to just say you CAN-NOT server this request and that is all. I fully 
> agree you don't need to disclose any detailed information, my view is 
> its just a yes I can serve or no I cant serve at this given time.
>
> Alan
>
> > As raised by Alan in his e-mail below, in an offload use case the 
> uCDN would require information on the dCDNs to be aware of the amount 
> of traffic it can offload to every dCDN. I think this requirement is 
> already covered through the request routing interface as REQ-2 
> includes the advertising of information about dCDN resources. Maybe we 
> might add a few words to REQ-2 to mention explicitly that resource 
> information could be needed for offload situations.
>
> This might not be what you meant (and if that's the case I apologise 
> and just ignore me) but I'm not convinced that the uCDN needs to know 
> how much capacity the dCDN has available. Instead it just needs to 
> know if the dCDN is prepared "to do more work" on behalf of the uCDN.
>
> Ben
>
> >
> > I am not 100% clear today if the offload use case introduces 
> specific requirements on other interfaces (e.g., control and metadata) 
> in addition to the request routing interface. I see some specificity 
> in this use case, for instance, the duration during which the uCDN 
> will use the dCDN resources can be short in an offload situation 
> (e.g., duration of a flash crowd) as compared to a footprint extension 
> use case.
> >
> > Best regards,
> >
> > Gilles
> >
> >
> > I agree: the CDN on which requests are offloaded must be able to 
> handle the offloaded requests. This (may)  introduce requirements on 
> the metadata (and control) interfaces.
> > A.K.--> Yes, my point exactly, it would be useful to point that out 
> in your draft to make it complete and also have it noted in the "CDNI 
> Requirements Draft" .
> > (...)
> >
> > (...)

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 21 Nov 2011 14:13:20 +0000

On 16 Nov 2011, at 02:15, Alan Kavanagh wrote:

> Sure here is some text it just needs to be captured. " dCDN Should inform the uCDN it can not handle any requests at this time",

Is the requirement that the "informing" is done via the "capabilities" request routing interface or the "redirection" request routing interface?

For example, is it sufficient for the dCDN to respond to a CDNI "redirection" interface request with "I cannot serve <delivery protocol X> to <location Y/subnet Z>" with a TTL that indicates the period for which such information can be reused by the uCDN without re-querying the dCDN?

Ben

> I dont think it needs to be noted as to why at a given instance of time the request can not be handled, if others feel different i would like to hear why. My only further comment is the oposite, i.e. to inform the uCDN when it can handle requests again. 
>  
> BR
> Alan
> 
> From: Alan Kavanagh <[email-masked]>
> To: "Kent Leung (kleung)" <[email-masked]>, "[email-masked]" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> _______________________________________________ CDNi mailing list [email-masked] https://www.ietf.org/mailman/listinfo/cdni

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Mon, 21 Nov 2011 09:47:25 -0800

Good discussions so far.  Just like to clarify some points.

1. It looks to me that the topic started off with a requirement for dCDN
to inform uCDN on the dCDN's available resources to handle offload use
case.  This seems to be covered in REQ-2 which generically advertises
such information as part of "capabilities" RRI.

2. Then the discussion turned to a need for requirement for dCDN to
notify the uCDN when overload condition occurred (i.e. request cannot be
handled by dCDN) or no longer the case (i.e. request can be handled
again).  This seems to be covered in REQ-14 which provides a generic
"redirection" RRI function. 

3. Then it seems a requirement for dCDN to convey more specific context
on why it cannot serve the request (e.g. delivery protocol to location
for period of time).  This seems to be more granular level of control
and additional timeliness to REQ-1.  Though I suspect that the new
requirement is considered [MED] instead of current priority of [HIGH]. 

Have I misinterpreted anything?  I'm not sure if the requirements for #1
and #2 need any updates.  If so, please provide text that does not
functionally overlap with the existing requirements.

As for #3, I'm not sure if the intent is to add additional requirements?

Kent

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: Monday, November 21, 2011 6:13 AM
To: Alan Kavanagh
Cc: Lee, Yiu; Kent Leung (kleung); [email-masked];
[email-masked]

On 16 Nov 2011, at 02:15, Alan Kavanagh wrote:

> Sure here is some text it just needs to be captured. " dCDN Should
inform the uCDN it can not handle any requests at this time",

Is the requirement that the "informing" is done via the "capabilities"
request routing interface or the "redirection" request routing
interface?

For example, is it sufficient for the dCDN to respond to a CDNI
"redirection" interface request with "I cannot serve <delivery protocol
X> to <location Y/subnet Z>" with a TTL that indicates the period for
which such information can be reused by the uCDN without re-querying the
dCDN?

Ben

> I dont think it needs to be noted as to why at a given instance of
time the request can not be handled, if others feel different i would
like to hear why. My only further comment is the oposite, i.e. to inform
the uCDN when it can handle requests again. 
> I struggle how explicit we need to put in the requirement. Do you
think a sub-bullet like: "information to signal overload to uCDN" is
sufficient? Can you suggest some text which you think REQ-2 doesn't
capture? We would like people to discuss the new text in the ML.
> To: "Kent Leung (kleung)" <[email-masked]>,
"[email-masked]" <[email-masked]>
> What might be useful is to jut capture the requirement somewhere as i
believe their will be numerous ways to address the overload case and i
can see changes required not just on CDN-I metadata i/f as GIlles is
pointing out too, so for now lets capture the requirement.
> The discussion below indicates a need for RRI requirement, which can
be traced to REQ-2.  Is this not sufficient?
> I agree: the CDN on which requests are offloaded must be able to
handle the offloaded requests. This (may)  introduce requirements on the
metadata (and control) interfaces. 
> (...)
> (...)
> _______________________________________________ CDNi mailing list
[email-masked] https://www.ietf.org/mailman/listinfo/cdni

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 21 Nov 2011 18:32:13 +0000

Kent,

> functionally overlap with the existing requirements.

My intent was not to add additional requirements but probe into the statement "dCDN Should inform the uCDN it can not handle any requests at this time" to determine what the actual, specific requirements are.

> As for #3, I'm not sure if the intent is to add additional requirements?

I think #3 is not required. E.g. delivery protocol is either explicit or implicit from the RRI request.

Ben

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Mon, 21 Nov 2011 16:36:09 -0800

Hi Ben.

> My intent was not to add additional requirements but probe into the
statement "dCDN Should  
> inform the uCDN it can not handle any requests at this time" to
determine what the actual, 
> specific requirements are.

KL> OK. This should be covered in REQ-14 and REQ-1.  I think you were
also trying to support the function below (i.e. indicate when dCDN will
be ready to handle request again)

<snip>
> the uCDN when it can handle requests again. 

KL> This requirement seems to be covered in REQ-1 already?  The solution
may be based on your proposed TTL method.  But that level of detail does
not need to be in the requirements draft, IMHO.

Kent

<snip>