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

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

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: zhangyunfei <[email-masked]>
Date: Wed, 30 Jan 2013 10:05:51 +0800

Hi Ray，
    Pls see inline. Thanks.

BR
Yunfei

zhangyunfei

From: Brandenburg, R. (Ray) van
Date: 2013-01-29 18:23
To: [email-masked]
CC: [email-masked]
Subject: [CDNi] Questions related to draft-he-cdni-routing-request-redirection-03
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. 
[Yunfei] It seems to make sense in the above example to support the connections with the metadata interface for RRRI in HAS case.I didn't attend last IETF,so I am not clear of the current status and conclusion of HAS in CDNI. Does CDNI consider the HAS case in current stage? 
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