Subject: Re: [CDNi] Questions related to draft-he-cdni-routing-request-redirection-03

From: Ben Niven-Jenkins <[email-masked]>
Date: Sat, 16 Feb 2013 15:52:28 +0000

Ray,

On 30 Jan 2013, at 09:23, Brandenburg, R. (Ray) van wrote:
> From: Ben Niven-Jenkins [mailto:[email-masked]] 
> On 29 Jan 2013, at 10:26, Brandenburg, R. (Ray) van wrote:
> 
>> I've reviewed draft-he-cdni-routing-request-redirection-03 and have some questions/comments:

I've addressed you comments in my working draft of -04 except these which I'd like to discuss further:

>> - How does the draft relate to work currently being done on the Metadata interface? Particularly in dealing with multiple files being described by the same (or higher level) metadata object.  In its current form, the draft specifies that a RRRI Request contains a URL to the metadata object associated with the  UA request. It might be useful to allow a dCDN to reply with a RRRI Response indicating that a particular reply is valid for a particular set of CDNI Metadata (not necessarily being the same set referenced by the uCDN). Such a feature would be particularly useful in HAS scenarios, where with the current draft you would have hundreds of RRRI Request for each individual segment. 
> 
> We might need to dig into this a bit more but...
> 
> My opinion is that request routing policy should only be set at the Host level and not the path level in CDNI metadata.
> 
> Allowing the dCDN to specify a scope against which the RRRI response applies is something we've already included. If we want to extend the current scope object we have defined I am OK with that but I'd like it to be based off specific use cases so we can explore the implications of doing so.
> 
> I guess I'm saying - can you articulate the use case around HAS you have in mind and then we can work through what would make sense to return in a RRRI response?
> 
> [Ray] So, the use case I have in mind is that a particular HAS content item consists of a couple of hundred segments. If we wouldn't do anything specific in the RRRI, this would mean that a separate RRRI Request and Response would be sent for every individual segment. For some CDNs this might be perfectly fine, and would allow them a fine granularity to do per-segment RR. However, it might perhaps be more efficient if it would be possible for a dCDN to reply with: 'Ok, here you go with the redirect response for this particular segment, and by the way, if you have any requests for segments associated with this one (indicated by metadata), you can also redirect them to me'.

If I understand correctly what you are really asking for is some method by which to indicate the scope of the RI response is wider than just the URI that triggered the RI request?

Returning some kind of URI pattern match (possibly extracted from the CDNI PathMetadata/PathMatch) seems appealing but I am not sure how realistic it would be to implement in practice.

I know of implementations that effectively hash URLs across surrogates for load balancing and other purposes, and I am not sure whether it would be feasible to generically describe such hashing algorithms (or whether implementors would be willing to expose their hashing/load balancing algorithms). 

>> - It might be useful to include in the draft a short note or comment that discusses byte range requests and how this is dealt with by the RRRI interface. 
> 
> Byte range requests are independent of request routing, or are you suggesting we should allow a dCDN to redirect to different surrogates based on the first byte range the original UA requests (which is a bad idea IMO)?
> 
> [Ray] I agree with you that something like that is not necessary. What I would like to see in the draft is a short discussion how both a uCDN and dCDN should interpret a RRRI Request/Response with regards to byte range request. So let's say the UA sends a request to the uCDN for a particular file with a particular byte range (e.g. for a Smooth Streaming fragment). The uCDN encapsulates this request and sends a RRRI Request to the dCDN. The dCDN replies with a RRRI Response. The question is what the scope of the RRRI Request and Response should be, is the scope limited to that particular byte range, or is it for the entire file. In other words: should the dCDN expect to receive additional RRRI Requests for other byte ranges of the same file or should it assume that is has agreed to also deliver any other byte ranges for that particular file? I'm not suggesting that we need any new functionality, I just think some definition of scope with regards to byte ranges and RRRI could be helpful. 

Byte ranges are no different to any other types of request in that regard. If the UA follows a redirect and holds a persistent connection to the surrogate, there will be no more RI requests. If the surrogate doesn't hold a persistent connection the UA will recontact the Request Router (either a uCDN Request Router or Redirection Target that is a request router returned in the original RI request) for the next request (normal or byte range). If the contacted request router is a uCDN request router, it can use any cacheability/scope of the previous RI response to redirect the UA without issuing another RI request to the dCDN. Otherwise if it decides to use dCDN again it must issue a new RI request.

So when a dCDN sends a RI response indicating it is willing to perform a delivery (whether the original request is for a byte rage or not) it is implicitly agreeing to delivery any further requests it receives from the UA either because the UA maintains a persistent connection or because the request routing performed means that the UA recontacts a Request Router outside of uCDN (e.g. dCDN's request router).

I'm not sure that the RI specification draft if the place to describe such things. If we put it anywhere it seems the framework would be a more appropriate place.

HTH
Ben

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Tue, 26 Feb 2013 14:14:46 +0000

Hi Ben, 

Thanks for addressing my comments. For the others, please see inline. 

For some of these issues, it might be good to have a meeting in Orlando to discuss them.

Best regards,

Ray

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: zaterdag 16 februari 2013 16:52
To: Brandenburg, R. (Ray) van
Cc: [email-masked]; [email-masked]
Subject: Re: [CDNi] Questions related to draft-he-cdni-routing-request-redirection-03

Ray,

On 30 Jan 2013, at 09:23, Brandenburg, R. (Ray) van wrote:
> From: Ben Niven-Jenkins [mailto:[email-masked]] On 29 Jan 
> 2013, at 10:26, Brandenburg, R. (Ray) van wrote:
> 

[Ray] Yes.

[Ray] I must admit that I'm not familiar with the mechanisms you describe, although from your explanation I don't see how this would be a problem. The node in the dCDN that responds to the uCDNs RRRI Request will have to be aware of the full URI, or else it would not be able to respond at all. Why wouldn't it be possible for this same node to respond with a wider scope? Of course such behavior should be optional. Maybe we can discuss this further in Orlando. 

[Ray] It is exactly that implicit assumption that I would like to make clear in the document, because it has a direct impact on a) the way a dCDN should acquire and cache content from the uCDN and b) the scope of the RRRI agreement between the dCDN and uCDN. Let me put it another way: let's say there is a 20GB file on the uCDN. At some point in time, the dCDN receives a request from the uCDN whether it would like to deliver a small portion (say 5mb byte range) of the larger file. With no assurance that the UA will come back for the rest of the file, should the dCDN acquire the entire file from the uCDN, or should it only acquire the requested byte range? 

[Ray] I agree that this could also be discussed in the framework document, but IMO it definitely should have a place in the RRRI document since it is directly related to the scope of the RRRI Request. 

HTH
Ben

This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer