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

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Tue, 29 Jan 2013 10:26:41 +0000

For some reason my bullets got lost. Let me try again:

____________________

Hi,
 
I've reviewed draft-he-cdni-routing-request-redirection-03 and have some questions/comments:
 
- Up until the protocol definition section, the draft makes the distinction between DNS and HTTP-based redirection. Would it be safe to say that 'HTTP' in this case is merely the primary example of 'media delivery protocol'? In other words, would it be possible to replace HTTP here with any delivery protocol that includes a redirect message (e.g. RTMP, RTSP, etc). If this is the case, than it might be useful to mention this early on in the draft.  

- In section 4.2 it is stated that for HTTP redirection, it should be possible for the uCDN to indicate whether it would like the dCDN to return an IP address or hostname to redirect to. Why is this necessary? Especially considering the fact that the draft defines that the HTTP response to the UA is being sent to the uCDN in encapsulated form, this shouldn't matter right?

- In section 5, bullet 4) it says 'The RR system of CDN B sends.', this should probably read 'The RR system of CDN A sends.'

- 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. 

- 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. 
 
Best regards,
 
Ray
 
This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 30 Jan 2013 08:55:28 +0000

Ray,

Thanks for the comments/questions, please see inline

> - Up until the protocol definition section, the draft makes the distinction between DNS and HTTP-based redirection. Would it be safe to say that 'HTTP' in this case is merely the primary example of…

Yes & no. From an abstract point of view HTTP is merely an example of a 'media delivery protocol' (but is the only one that the WG is focussed on in the short term IIRC).

From a specific protocol point of view what needs to be in the messages will likely vary by application protocol - e.g. RTMP has the concept of a streamname we'd need to communicate so can;t just re-use what we have defined so far for HTTP as-is but could use something extremely similar.

The draft should probably more clearly differentiate between when we're talking about "application level redirection" at an abstract level versus HTTP as a specific "application protocol" the request routing interface is defining support for.

> - In section 4.2 it is stated that for HTTP redirection, it should be possible for the uCDN to indicate whether it would like the dCDN to return an IP address or hostname to redirect to. Why is thi…

The original thinking was a uCDN may prefer IP address over hostname to save a DNS lookup/request. Since writing the -03 version I've changed my view and don't think the uCDN should be able to control that, it should instead be down to the dCDN to determine what it wants to return.
 
> - In section 5, bullet 4) it says 'The RR system of CDN B sends.', this should probably read 'The RR system of CDN A sends.'

Thanks, will correct in the next revision (which we hope to have ready in a few weeks time along with the other updates we promised at the Atlanta IETF).

> - 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 it…

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?

> - 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)?

Ben

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

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Wed, 30 Jan 2013 09:23:28 +0000

Hi Ben,

See inline.

Ray

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

Ray,

[Ray] Seems we agree on this point.

[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'.

[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. 

Ben