From flefauch@cisco.com Mon Jan 14 05:38:39 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08DD121F86FF for ; Mon, 14 Jan 2013 05:38:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.679 X-Spam-Level: X-Spam-Status: No, score=-9.679 tagged_above=-999 required=5 tests=[AWL=-0.920, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXR5aCF6bWEp for ; Mon, 14 Jan 2013 05:38:37 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 21BF221F86CC for ; Mon, 14 Jan 2013 05:38:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10451; q=dns/txt; s=iport; t=1358170709; x=1359380309; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=fFGjBiuTOFEQxkMAw56C9FOufnT7wR7V2zMQSFHVf+A=; b=iqcQIzJ4IuqkiYEeezEHiUQZYBF0HbNH+dsb7syTME+cQ4y4NgCCPWiw NuJhB5uwz8hMtrOBxbIrLUisxvL8WCrisZ3slqaspB1yo6MX0fVnM4hSF T0lJHJcpkq/LkwkjU9FAQhupYEZO/cSX6UUH9fIRaDE/AR43lZwjtoqYy I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAOEI9FCtJXG//2dsb2JhbAAqFQIDvXwWc4IeAQEBAgEBAQEBJD8CBgYKCwIBCBQECgoEDAonCyQBAgEDEwiICwYMLKd5jAeMawsbA2wHgkZhA6ZUgiVQgW81 X-IronPort-AV: E=Sophos;i="4.84,468,1355097600"; d="scan'208";a="159125302" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 14 Jan 2013 13:38:27 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r0EDcRBe003514 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 14 Jan 2013 13:38:27 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.229]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Mon, 14 Jan 2013 07:38:27 -0600 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: [CDNi] CDNI Logging - 2 proposals for scoping of the first version of the CDNI interfaces Thread-Index: AQHN8lxupVqi/pCMr0ycN+90WW/fSg== Date: Mon, 14 Jan 2013 13:38:26 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.201] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] CDNI Logging - 2 proposals for scoping of the first version of the CDNI interfaces X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 13:38:39 -0000 Folks, Since we haven't heard any disagreement with the two proposals below, we'll= move ahead with those. Cheers Francois On 20 Dec 2012, at 11:45, Francois Le Faucheur (flefauch) wrote: > Folks, >=20 > (speaking as an individual) >=20 > As announced earlier, a bunch of us (1) interested in CDNI Logging had an= informal discussion around two aspects of CDNI Logging Yesterday. We conve= rged on two proposals detailed below for which we are solliciting comments.= Please review those and pass on the comments you may have, so the WG can m= ake a decision on those. >=20 >=20 > Proposal 1: > =3D=3D=3D=3D=3D=3D=3D=3D=20 > o Aim to support in the first version of the CDNI interfaces: > * customizable set of CDNI Logging fields (e.g. include a customizable = set of logging information elements in a given log - possibly with a defaul= t set) > * customizable set of CDNI Logging events (e.g. include logs for a cust= omizable set of events -eg for delivery but not for redirection) > o Do _not_ aim to support in the first version of the CDNI interfaces: > * a signaling mechanism to control such Logging customization. >=20 > The rationale behind this proposal includes: > * for initial CDNI deployments, it is reasonable to rely on "management = plane". In other words, humans in uCDN and dCDN can agree on what events ar= e to be logged by the other CDN and what set of logging fields are to be in= cluded, and then humans in uCDN and dCDN can configure their CDNI Logging s= ystems accordingly. > * while a signaling mechanism allowing automation of such customization = would be nice (and is a good candidate work item if/when CDNI WG recharters= ) it is not an absolute-must-have for initial deployment > * defining such a signaling mechanism would require non-negligible time = and energy, that may be better spent in the short term on developing the CD= NI Logging interface itself that is not progressing as fast as needed >=20 > Additional points: > * there was no convergence among us on which CDNI interface (CDNI Contro= l or CDNI Metadata) should be used for signaling CDNI Logging customization= /control, if/when we decide to specify that > * authors of the CDNI Metadata interface felt it is likely that the Meta= data interface could be extended later to support CDNI Logging customizatio= n/control, if/when we decide to specify it and if we decide to include it i= n the CDNI Metadata interface. Authors of the CDNI Metadata are requested t= o keep this topic in the back of their head to facilitate such potential ex= tension > * If the CDNI Control interface was to be used for CDNI Logging customiz= ation/control, the necessary mechanism would be quite different from the CD= NI Trigger proposal because CDNI Logging customization/control requires per= sistence of state. >=20 >=20 >=20 > Proposal 2:=20 > =3D=3D=3D=3D=3D=3D=3D=3D > o Aim to support in the first version of the CDNI interfaces: > * CDNI Logging in the dCDN-->uCDN direction > o Do _not_ aim to support in the first version of the CDNI interfaces: > * CDNI Logging in the uCDN-->dCDN direction >=20 > The rationale behind this proposal includes: > * there is unanimous agreement that CDNI Logging in the dCDN-->uCDN dire= ction is urgently needed > * we did not convergence on whether CDNI Logging in the uCDN-->dCDN dire= ction is really needed and what are the exact use cases for it > * while a few felt that it would probably be useful to have the ability = to pass CDNI Logs in the uCDN-->dCDN direction, it is clearly not an absolu= te-must-have for initial deployment > * since the CDNI Logging protocol itself (whether built on Syslog, IPFIX= , web-services,=85) is likely to pass information in one direction, adding = logs in the opposite direction can be easily done at a later stage by addin= g another instance of the same protocol with opposite roles on both ends.=20 > * defining CDNI Logging in the uCDN-->dCDN direction would require non-n= egligible time and energy, that may be better spent in the short term on de= veloping CDNI Logging in the dCDN-->uCDN direction that is not progressing = as fast as needed >=20 >=20 > Francois >=20 >=20 > (1) Gilles B, Roy P, Emile S, Kevin M, Rob M, Ray v B, Bhumip K, Iuniana,= Rich W, Francois LF & a few others part of the time. >=20 >=20 > On 18 Dec 2012, at 19:29, Francois Le Faucheur (flefauch) wrote: >=20 >> Just a friendly reminder about tomorrow's informal discussion (08:00 PST= =3D 11:00 EST =3D 17:00 CET). >> Talk to you then. >> Francois >>=20 >> On 29 Nov 2012, at 11:28, Francois Le Faucheur wrote: >>=20 >>> Folks, >>>=20 >>> Meeting has been rescheduled to 19 Dec. So here are the updated details= : >>>=20 >>> Date: Wednesday 19 December 2012 >>> Start: 08:00 PST aka 17:00 CET >>> Duration: 90 mins >>> Webex details: see below >>>=20 >>> Please mark this in your agenda if you are interested in attending. >>>=20 >>> Again, note that this is not a formal session nor an IETF Interim Meeti= ng. Just an informal discussion to exchange views on that topic. >>>=20 >>> Francois >>>=20 >>>=20 >>>=20 >>> Webex details: >>>=20 >>> Topic: CDNI Logging Customization/Control=20 >>> Date: Wednesday, December 19, 2012=20 >>> Time: 5:00 pm, Europe Time (Paris, GMT+01:00)=20 >>> Meeting Number: 207 377 422=20 >>> Password: cdni=20 >>>=20 >>> -------------------------------------------------------=20 >>> To join the meeting online=20 >>> -------------------------------------------------------=20 >>> 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D211252322&UID=3D= 484318167&PW=3DNMTM0ZDI5MmM0&RT=3DMiMyMw%3D%3D=20 >>> 2. If requested, enter your name and email address.=20 >>> 3. If a password is required, enter the meeting password: cdni=20 >>> 4. Click "Join".=20 >>> 5. If the meeting includes a teleconference, follow the instructions th= at appear on your screen.=20 >>>=20 >>> -------------------------------------------------------=20 >>> To join the audio conference only=20 >>> -------------------------------------------------------=20 >>> To receive a call back, provide your phone number when you join the mee= ting, or call the number below and enter the access code.=20 >>> Call-in toll-free number (US/Canada): +1-866-432-9903=20 >>> Call-in toll number (US/Canada): +1-408-525-6800=20 >>> Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restr= ictions.pdf=20 >>>=20 >>> Access code:207 377 422=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> CCP:+14085256800x207377422#=20 >>>=20 >>> IMPORTANT NOTICE: This WebEx service includes a feature that allows aud= io and any documents and other materials exchanged or viewed during the ses= sion to be recorded. By joining this session, you automatically consent to = such recordings. If you do not consent to the recording, discuss your conce= rns with the meeting host prior to the start of the recording or do not joi= n the session. Please note that any such recordings may be subject to disco= very in the event of litigation.=20 >>>=20 >>> On 28 Nov 2012, at 16:19, Francois Le Faucheur (flefauch) wrote: >>>=20 >>>> Hi, >>>>=20 >>>> It appeared in Atlanta that we need more discussion to conclude on whi= ch CDNI interface (CI or MI) is to be used for customization/control of CDN= I Logging. >>>>=20 >>>> To facilitate an informal discussion on that topic, I have setup a Web= ex session for remote participation: >>>> Date: Wednesday 12 December 2012 >>>> Start: 08:00 PST aka 17:00 CET >>>> Duration: 90 mins >>>> Webex details: see below >>>>=20 >>>> Please mark this in your agenda if you are interested in attending. >>>>=20 >>>> Again, note that this is not a formal session nor an IETF Interim Meet= ing. Just an informal discussion to exchange views on that topic. >>>>=20 >>>> Cheers >>>>=20 >>>> Francois=20 >>>>=20 >>>>=20 >>>> Topic: CDNI Logging Customization/Control=20 >>>> Date: Wednesday, December 12, 2012=20 >>>> Time: 5:00 pm, Europe Time (Paris, GMT+01:00)=20 >>>> Meeting Number: 207 377 422=20 >>>> Password: cdni=20 >>>>=20 >>>> -------------------------------------------------------=20 >>>> To join the meeting online(Now from mobile devices!)=20 >>>> -------------------------------------------------------=20 >>>> 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D211252322&UID= =3D484318167&PW=3DNMTM0ZDI5MmM0&RT=3DMiMyMw%3D%3D=20 >>>> 2. If requested, enter your name and email address.=20 >>>> 3. If a password is required, enter the meeting password: cdni=20 >>>> 4. Click "Join".=20 >>>> 5. If the meeting includes a teleconference, follow the instructions t= hat appear on your screen.=20 >>>>=20 >>>> -------------------------------------------------------=20 >>>> To join the audio conference only=20 >>>> -------------------------------------------------------=20 >>>> To receive a call back, provide your phone number when you join the me= eting, or call the number below and enter the access code.=20 >>>> Call-in toll-free number (US/Canada): +1-866-432-9903=20 >>>> Call-in toll number (US/Canada): +1-408-525-6800=20 >>>> Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_rest= rictions.pdf=20 >>>>=20 >>>> Access code:207 377 422=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> CCP:+14085256800x207377422#=20 >>>>=20 >>>> IMPORTANT NOTICE: This WebEx service includes a feature that allows au= dio and any documents and other materials exchanged or viewed during the se= ssion to be recorded. By joining this session, you automatically consent to= such recordings. If you do not consent to the recording, discuss your conc= erns with the meeting host prior to the start of the recording or do not jo= in the session. Please note that any such recordings may be subject to disc= overy in the event of litigation.=20 >>>> _______________________________________________ >>>> CDNi mailing list >>>> CDNi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/cdni >>>=20 >>=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From jeroen.famaey@intec.ugent.be Thu Jan 24 01:23:05 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 029F321F8843 for ; Thu, 24 Jan 2013 01:23:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMC6e-XB53Lf for ; Thu, 24 Jan 2013 01:23:04 -0800 (PST) Received: from smtp2.ugent.be (smtp2.ugent.be [157.193.49.126]) by ietfa.amsl.com (Postfix) with ESMTP id 8C02221F87FD for ; Thu, 24 Jan 2013 01:23:03 -0800 (PST) Received: from localhost (mcheck2.ugent.be [157.193.49.249]) by smtp2.ugent.be (Postfix) with ESMTP id 8375412C26E for ; Thu, 24 Jan 2013 10:23:02 +0100 (CET) X-Virus-Scanned: by UGent DICT Received: from smtp2.ugent.be ([157.193.49.126]) by localhost (mcheck2.UGent.be [157.193.43.11]) (amavisd-new, port 10024) with ESMTP id szgEwCLy_twa for ; Thu, 24 Jan 2013 10:23:02 +0100 (CET) Received: from mail2.intec.ugent.be (mail2.intec.ugent.be [157.193.214.245]) by smtp2.ugent.be (Postfix) with ESMTP id 1B21112C263 for ; Thu, 24 Jan 2013 10:23:02 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail2.intec.ugent.be (Postfix) with ESMTP id 1AE4A1F for ; Thu, 24 Jan 2013 10:23:02 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at intec.ugent.be Received: from mail2.intec.ugent.be ([127.0.0.1]) by localhost (mail2.intec.ugent.be [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id faDwk+BCBtrM for ; Thu, 24 Jan 2013 10:23:02 +0100 (CET) Received: from [10.10.130.4] (visitors.ibbt.be [193.191.148.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jfamaey) by mail2.intec.ugent.be (Postfix) with ESMTPSA id 043701E for ; Thu, 24 Jan 2013 10:23:02 +0100 (CET) From: Jeroen Famaey Content-Type: multipart/alternative; boundary="Apple-Mail=_D5ED0E63-233A-4579-9D08-BD570DBE8EFE" Date: Thu, 24 Jan 2013 10:23:01 +0100 References: <20130124091403.5033.96761.idtracker@ietfa.amsl.com> To: "cdni@ietf.org" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Miltered: at jchkm3 with ID 5100FD76.000 by Joe's j-chkmail (http://helpdesk.ugent.be/email/)! X-j-chkmail-Enveloppe: 5100FD76.000 from mail2.intec.ugent.be/mail2.intec.ugent.be/157.193.214.245/mail2.intec.ugent.be/ X-j-chkmail-Score: MSGID : 5100FD76.000 on smtp2.ugent.be : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Subject: [CDNi] Fwd: New Version Notification for draft-famaey-cdni-has-experiments-01.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 09:23:05 -0000 --Apple-Mail=_D5ED0E63-233A-4579-9D08-BD570DBE8EFE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear all, We have just submitted a new version of Internet Draft = "draft-famaey-cdni-has-experiments". It contains several new = experimental results on the effects of inter-CDN request routing on the = QoE of HTTP Adaptive Streaming (HAS) services. The newly conducted = experiments are based on feedback by several CDNi working group members, = for which we are thankful. Specifically, the new results consider = network congestion, downstream CDNs with high latency, effect on buffer = starvation, content hosted at the upstream CDN in addition to the = downstream CDN and influence of HAS segment duration. Kind regards, Jeroen Famaey -- Dr. Jeroen Famaey Department of Information Technology Internet Based Communication Networks and Services (IBCN) Ghent University - iMinds Gaston Crommenlaan 8 (Bus 201), B-9050 Gent, Belgium T: +32 9 33 14938; T Secr: +32 (0)9 33 14900 F: +32 9 33 14899 E: jeroen.famaey@intec.UGent.be W: http://users.ugent.be/~jfamaey W: http://www.ibcn.intec.UGent.be=20 Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-famaey-cdni-has-experiments-01.txt > Date: 24 Jan 2013 10:14:03 GMT+01:00 > To: jeroen.famaey@intec.ugent.be > Cc: steven.latre@intec.ugent.be >=20 >=20 > A new version of I-D, draft-famaey-cdni-has-experiments-01.txt > has been successfully submitted by Jeroen Famaey and posted to the > IETF repository. >=20 > Filename: draft-famaey-cdni-has-experiments > Revision: 01 > Title: Experiments on HTTP Adaptive Streaming over = interconnected Content Delivery Networks > Creation date: 2013-01-24 > WG ID: Individual Submission > Number of pages: 15 > URL: = http://www.ietf.org/internet-drafts/draft-famaey-cdni-has-experiments-01.t= xt > Status: = http://datatracker.ietf.org/doc/draft-famaey-cdni-has-experiments > Htmlized: = http://tools.ietf.org/html/draft-famaey-cdni-has-experiments-01 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-famaey-cdni-has-experiments-01 >=20 > Abstract: > This document reports experimental results on the delivery of HTTP > Adaptive Streaming (HAS) content over interconnected Content = Delivery > Networks (CDNs). Specifically, the implications that CDN request > routing between CDNs and HTTP redirection have on the quality of > delivered HAS content are investigated. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 --Apple-Mail=_D5ED0E63-233A-4579-9D08-BD570DBE8EFE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear = all,

We have just submitted a new version of Internet = Draft "draft-famaey-cdni-has-experiments".  It contains several new = experimental results on the effects of inter-CDN request routing on the = QoE of HTTP Adaptive Streaming (HAS) services.  The newly conducted = experiments are based on feedback by several CDNi working group members, = for which we are thankful.  Specifically, the new results consider = network congestion, downstream CDNs with high latency, effect on buffer = starvation, content hosted at the upstream CDN in addition to the = downstream CDN and influence of HAS segment = duration.

Kind regards,
Jeroen = Famaey

--
Dr. Jeroen Famaey
Department of Information = Technology
Internet Based Communication Networks and Services = (IBCN)
Ghent University - iMinds
Gaston Crommenlaan 8 (Bus 201), = B-9050 Gent, Belgium
T: +32 9 33 14938; T Secr: +32 (0)9 33 = 14900
F: +32 9 33 14899
E: jeroen.famaey@intec.UGent.be<= /a>
W: http://users.ugent.be/~jfamaey=
W: http://www.ibcn.intec.UGent.be=  



Begin forwarded message:

Subject: New Version Notification for = draft-famaey-cdni-has-experiments-01.txt
Date: 24 Jan 2013 = 10:14:03 GMT+01:00


A new version of I-D, = draft-famaey-cdni-has-experiments-01.txt
has been successfully = submitted by Jeroen Famaey and posted to the
IETF = repository.

Filename: = draft-famaey-cdni-has-experiments
Revision: = 01
Title: = = Experiments on HTTP Adaptive Streaming over interconnected = Content Delivery Networks
Creation date: 2013-01-24
WG ID: = Individual Submission
Number of pages: 15
URL: =             http://www.ietf.org/internet-drafts/draft-famaey-cdni-has-expe= riments-01.txt
Status: =          http://datatracker.ietf.org/doc/draft-famaey-cdni-has-experiments
= Htmlized:        h= ttp://tools.ietf.org/html/draft-famaey-cdni-has-experiments-01
Diff= :            http://www.ietf.org/rfcdiff?url2=3Ddraft-famaey-cdni-has-experiment= s-01

Abstract:
  This document reports = experimental results on the delivery of HTTP
  Adaptive = Streaming (HAS) content over interconnected Content Delivery
=   Networks (CDNs).  Specifically, the implications that = CDN request
  routing between CDNs and HTTP redirection = have on the quality of
  delivered HAS content are = investigated.




The IETF = Secretariat


= --Apple-Mail=_D5ED0E63-233A-4579-9D08-BD570DBE8EFE-- From ray.vanbrandenburg@tno.nl Tue Jan 29 02:23:49 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9C121F854E for ; Tue, 29 Jan 2013 02:23:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LITg5-wnF0P5 for ; Tue, 29 Jan 2013 02:23:47 -0800 (PST) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id 031EB21F8581 for ; Tue, 29 Jan 2013 02:23:46 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,559,1355094000"; d="scan'208,217";a="3271196" Received: from unknown (HELO mail.tno.nl) ([134.221.225.220]) by mailhost1a.tno.nl with ESMTP; 29 Jan 2013 11:23:40 +0100 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.230]) by EXC-CASHUB01.tsn.tno.nl ([134.221.225.220]) with mapi id 14.02.0318.004; Tue, 29 Jan 2013 11:23:40 +0100 From: "Brandenburg, R. (Ray) van" To: "draft-he-cdni-routing-request-redirection@tools.ietf.org" Thread-Topic: Questions related to draft-he-cdni-routing-request-redirection-03 Thread-Index: Ac3+CrAfKBrvbP7DQ1utva8400dGNw== Date: Tue, 29 Jan 2013 10:23:39 +0000 Message-ID: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.153] Content-Type: multipart/alternative; boundary="_000_FCC100FC8D6B034CB88CD8173B2DA1581C99CE0EEXCMBX03tsntnon_" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: [CDNi] Questions related to draft-he-cdni-routing-request-redirection-03 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 10:23:49 -0000 --_000_FCC100FC8D6B034CB88CD8173B2DA1581C99CE0EEXCMBX03tsntnon_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi, I've reviewed draft-he-cdni-routing-request-redirection-03 and have some qu= estions/comments: - Up until the protocol definition section, the draft makes the disti= nction 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 proto= col'? In other words, would it be possible to replace HTTP here with any de= livery 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? Especiall= y 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 r= ight? - 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 Metad= ata interface? Particularly in dealing with multiple files being described = by the same (or higher level) metadata object. In its current form, the dr= aft specifies that a RRRI Request contains a URL to the metadata object ass= ociated with the UA request. It might be useful to allow a dCDN to reply w= ith a RRRI Response indicating that a particular reply is valid for a parti= cular set of CDNI Metadata (not necessarily being the same set referenced b= y 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 ea= ch 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 i= nterface. Best regards, Ray This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer --_000_FCC100FC8D6B034CB88CD8173B2DA1581C99CE0EEXCMBX03tsntnon_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable
Hi,
 
I’ve reviewed draft-he-cdni-routing-request-redirection-03 and h= ave some questions/comments:
 
  • Up until the protocol definition section, the draft makes the distincti= on between DNS and HTTP-based redirection. Would it be safe to say that = 216;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 me= ssage (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 ind= icate 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 t= he draft defines that the HTTP response to the UA is being sent to the uCDN in encap= sulated form, this shouldn’t matter right?
  • In section 5, bull= et 4) it says ‘The RR system of CDN B sends…’, this shoul= d probably read ‘The RR system of CDN A sends…’
  • H= ow does the draft relate to work currently being done on the Metadata inter= face? Particularly in dealing with multiple files being described by the sa= me (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 necess= arily being the same set referenced by the uCDN). Such a feature would be particularly useful in HAS scenarios, wh= ere 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 de= alt 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

--_000_FCC100FC8D6B034CB88CD8173B2DA1581C99CE0EEXCMBX03tsntnon_-- From ray.vanbrandenburg@tno.nl Tue Jan 29 02:26:47 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54D8E21F862B for ; Tue, 29 Jan 2013 02:26:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ST6e51d7Wlc for ; Tue, 29 Jan 2013 02:26:46 -0800 (PST) Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 436BF21F8581 for ; Tue, 29 Jan 2013 02:26:46 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,559,1355094000"; d="scan'208";a="598094" Received: from unknown (HELO mail.tno.nl) ([134.221.225.220]) by mailhost1b.tno.nl with ESMTP; 29 Jan 2013 11:26:42 +0100 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.230]) by EXC-CASHUB01.tsn.tno.nl ([134.221.225.220]) with mapi id 14.02.0318.004; Tue, 29 Jan 2013 11:26:42 +0100 From: "Brandenburg, R. (Ray) van" To: "draft-he-cdni-routing-request-redirection@tools.ietf.org" Thread-Topic: [CDNi] Questions related to draft-he-cdni-routing-request-redirection-03 Thread-Index: Ac3+CyCOfZBkCVayTgyIK1hc6aa1UQ== Date: Tue, 29 Jan 2013 10:26:41 +0000 Message-ID: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.153] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: "cdni@ietf.org" Subject: Re: [CDNi] Questions related to draft-he-cdni-routing-request-redirection-03 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 10:26:47 -0000 For some reason my bullets got lost. Let me try again: ____________________ Hi, =A0 I've reviewed draft-he-cdni-routing-request-redirection-03 and have some qu= estions/comments: =A0 - 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.= =A0 = - In section 4.2 it is stated that for HTTP redirection, it should be possi= ble 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 cons= idering 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 sho= uld probably read 'The RR system of CDN A sends.' - How does the draft relate to work currently being done on the Metadata in= terface? Particularly in dealing with multiple files being described by the= same (or higher level) metadata object.=A0 In its current form, the draft = specifies that a RRRI Request contains a URL to the metadata object associa= ted with the=A0 UA request. It might be useful to allow a dCDN to reply wit= h a RRRI Response indicating that a particular reply is valid for a particu= lar set of CDNI Metadata (not necessarily being the same set referenced by = the uCDN). Such a feature would be particularly useful in HAS scenarios, wh= ere 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 d= iscusses byte range requests and how this is dealt with by the RRRI interfa= ce. = =A0 Best regards, =A0 Ray =A0 This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer From ray.vanbrandenburg@tno.nl Tue Jan 29 04:02:25 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D03B021F87CE for ; Tue, 29 Jan 2013 04:02:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cLpk9P3H+IG for ; Tue, 29 Jan 2013 04:02:20 -0800 (PST) Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 1791721F868E for ; Tue, 29 Jan 2013 04:02:07 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,559,1355094000"; d="scan'208";a="599249" Received: from unknown (HELO mail.tno.nl) ([134.221.225.221]) by mailhost1b.tno.nl with ESMTP; 29 Jan 2013 13:02:07 +0100 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.230]) by EXC-CASHUB02.tsn.tno.nl ([134.221.225.221]) with mapi id 14.02.0318.004; Tue, 29 Jan 2013 13:02:06 +0100 From: "Brandenburg, R. (Ray) van" To: "cdni@ietf.org" Thread-Topic: Review of draft-leung-cdni-uri-signing-01 Thread-Index: Ac3+GG4NUhcujNflQZSMkg63fGoAbw== Date: Tue, 29 Jan 2013 12:02:05 +0000 Message-ID: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.153] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: [CDNi] Review of draft-leung-cdni-uri-signing-01 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 12:02:26 -0000 Hi Kent, Francois, Matt, I've reviewed draft-leung-cdni-uri-signing-01 and have a couple of comments= . = - In its current form, the draft seems to lack a section that deals with th= e concept of URI signing from more of a system/high-level perspective. Such= a section could explain how the signed URI is being used between the CSP, = uCDN and dCDN respectively. As an example: the current draft seems to imply= that the same Signed URI that is created by the CSP is checked by the dCDN= . An alternative would be to have each transcient CDN 're-sign' the URI, re= ducing the number of parties that need to have access to a CSP key (in the = case of symmetric keys). I would imagine a section in the draft that explai= ns the trade-offs between these choices and argumentation why a specific me= thod was chosen. - The draft would benefit from a clear division between the general concept= s behind URI signing and the specific algorithm that is proposed in section= 3. I would assume that since the draft introduces the ALG field, that the = method described in the latter part of section 3 is just one example (altho= ugh maybe a preferred/recommended one) of such an algorithm. - In either the terminology section or the overview, it might be useful to = spend a few sentences on explaining your concept of 'key' and what it repre= sents. From reading the document, it seems that keys are being used in two = ways: 1) as a salt for cryptographic hashes such as SHA-1 or MD5, and 2) as= encryption/decryption keys in case the URI signing algorithm specifies tha= t the result of the hash should be encrypted (primarily in cases where asym= metric keys are used). The way the document is written right now, this seco= nd use of the 'key' concept is relatively 'hidden' from the casual reader. = Considering the fact that you mention asymmetric keys early on, this can co= nfuse the reader, since the combination of hashes and asymmetric keys seems= odd. Maybe it would be even better to use two different terms for the two = uses that 'key' seems to have. = - In the same way that section 2 defines the HF field, shouldn't it also de= fine something like an Encryption Function (EF) field, to define the specif= ic form of encryption used in the case asymmetric keys are used? Alternativ= ely, both the HF and EF fields could also be a function of the ALG field, r= educing the number of necessary fields in the URI. = - It could be useful to divide the list of attributes in section 2 into a l= ist containing attributes used for checking the validity of a given request= (e.g. the ET and CIP fields) and a list containing attributes used for re-= calculating the signature (e.g. the ALG, HF, KO and KN fields). = - What is the semantic distinction between the CIP and CID fields, apart fr= om the fact that CIP could be considered a specific case of CID? = Best regards, Ray This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer From zhangyunfei@chinamobile.com Tue Jan 29 18:06:08 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C91121F8991 for ; Tue, 29 Jan 2013 18:06:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.71 X-Spam-Level: X-Spam-Status: No, score=-94.71 tagged_above=-999 required=5 tests=[AWL=-1.241, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7eXHMgWJaobW for ; Tue, 29 Jan 2013 18:06:06 -0800 (PST) Received: from mail.chinamobile.com (unknown [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id D754121F898A for ; Tue, 29 Jan 2013 18:06:05 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.20.11]) by rmmx-oa_allagent02-12002 (RichMail) with SMTP id 2ee251087ff9942-3c942; Wed, 30 Jan 2013 10:05:45 +0800 (CST) X-RM-TRANSID: 2ee251087ff9942-3c942 Received: from zyf-PC (unknown[10.2.43.220]) by rmsmtp-oa_rmapp01-12001 (RichMail) with SMTP id 2ee151087ff53b0-d4670; Wed, 30 Jan 2013 10:05:45 +0800 (CST) X-RM-TRANSID: 2ee151087ff53b0-d4670 Date: Wed, 30 Jan 2013 10:05:51 +0800 From: zhangyunfei To: =?gb2312?B?QnJhbmRlbmJ1cmcsIFIuIChSYXkpIHZhbg==?= , "draft-he-cdni-routing-request-redirection@tools.ietf.org" References: X-Priority: 3 X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2013013010055148647398@chinamobile.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart465168505386_=----" Cc: "cdni@ietf.org" Subject: Re: [CDNi] Questions related to draft-he-cdni-routing-request-redirection-03 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhangyunfei List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 02:06:08 -0000 This is a multi-part message in MIME format. ------=_001_NextPart465168505386_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgUmF5o6wNCiAgICBQbHMgc2VlIGlubGluZS4gVGhhbmtzLg0KDQpCUg0KWXVuZmVpDQoNCg0K DQoNCnpoYW5neXVuZmVpDQoNCkZyb206IEJyYW5kZW5idXJnLCBSLiAoUmF5KSB2YW4NCkRhdGU6 IDIwMTMtMDEtMjkgMTg6MjMNClRvOiBkcmFmdC1oZS1jZG5pLXJvdXRpbmctcmVxdWVzdC1yZWRp cmVjdGlvbkB0b29scy5pZXRmLm9yZw0KQ0M6IGNkbmlAaWV0Zi5vcmcNClN1YmplY3Q6IFtDRE5p XSBRdWVzdGlvbnMgcmVsYXRlZCB0byBkcmFmdC1oZS1jZG5pLXJvdXRpbmctcmVxdWVzdC1yZWRp cmVjdGlvbi0wMw0KSGksDQoNCkmhr3ZlIHJldmlld2VkIGRyYWZ0LWhlLWNkbmktcm91dGluZy1y ZXF1ZXN0LXJlZGlyZWN0aW9uLTAzIGFuZCBoYXZlIHNvbWUgcXVlc3Rpb25zL2NvbW1lbnRzOg0K DQpVcCB1bnRpbCB0aGUgcHJvdG9jb2wgZGVmaW5pdGlvbiBzZWN0aW9uLCB0aGUgZHJhZnQgbWFr ZXMgdGhlIGRpc3RpbmN0aW9uIGJldHdlZW4gRE5TIGFuZCBIVFRQLWJhc2VkIHJlZGlyZWN0aW9u LiBXb3VsZCBpdCBiZSBzYWZlIHRvIHNheSB0aGF0IKGuSFRUUKGvIGluIHRoaXMgY2FzZSBpcyBt ZXJlbHkgdGhlIHByaW1hcnkgZXhhbXBsZSBvZiChrm1lZGlhIGRlbGl2ZXJ5IHByb3RvY29soa8/ IEluIG90aGVyIHdvcmRzLCB3b3VsZCBpdCBiZSBwb3NzaWJsZSB0byByZXBsYWNlIEhUVFAgaGVy ZSB3aXRoIGFueSBkZWxpdmVyeSBwcm90b2NvbCB0aGF0IGluY2x1ZGVzIGEgcmVkaXJlY3QgbWVz c2FnZSAoZS5nLiBSVE1QLCBSVFNQLCBldGMpLiBJZiB0aGlzIGlzIHRoZSBjYXNlLCB0aGFuIGl0 IG1pZ2h0IGJlIHVzZWZ1bCB0byBtZW50aW9uIHRoaXMgZWFybHkgb24gaW4gdGhlIGRyYWZ0LiAg DQpJbiBzZWN0aW9uIDQuMiBpdCBpcyBzdGF0ZWQgdGhhdCBmb3IgSFRUUCByZWRpcmVjdGlvbiwg aXQgc2hvdWxkIGJlIHBvc3NpYmxlIGZvciB0aGUgdUNETiB0byBpbmRpY2F0ZSB3aGV0aGVyIGl0 IHdvdWxkIGxpa2UgdGhlIGRDRE4gdG8gcmV0dXJuIGFuIElQIGFkZHJlc3Mgb3IgaG9zdG5hbWUg dG8gcmVkaXJlY3QgdG8uIFdoeSBpcyB0aGlzIG5lY2Vzc2FyeT8gRXNwZWNpYWxseSBjb25zaWRl cmluZyB0aGUgZmFjdCB0aGF0IHRoZSBkcmFmdCBkZWZpbmVzIHRoYXQgdGhlIEhUVFAgcmVzcG9u c2UgdG8gdGhlIFVBIGlzIGJlaW5nIHNlbnQgdG8gdGhlIHVDRE4gaW4gZW5jYXBzdWxhdGVkIGZv cm0sIHRoaXMgc2hvdWxkbqGvdCBtYXR0ZXIgcmlnaHQ/DQpJbiBzZWN0aW9uIDUsIGJ1bGxldCA0 KSBpdCBzYXlzIKGuVGhlIFJSIHN5c3RlbSBvZiBDRE4gQiBzZW5kc6Gtoa8sIHRoaXMgc2hvdWxk IHByb2JhYmx5IHJlYWQgoa5UaGUgUlIgc3lzdGVtIG9mIENETiBBIHNlbmRzoa2hrw0KSG93IGRv ZXMgdGhlIGRyYWZ0IHJlbGF0ZSB0byB3b3JrIGN1cnJlbnRseSBiZWluZyBkb25lIG9uIHRoZSBN ZXRhZGF0YSBpbnRlcmZhY2U/IFBhcnRpY3VsYXJseSBpbiBkZWFsaW5nIHdpdGggbXVsdGlwbGUg ZmlsZXMgYmVpbmcgZGVzY3JpYmVkIGJ5IHRoZSBzYW1lIChvciBoaWdoZXIgbGV2ZWwpIG1ldGFk YXRhIG9iamVjdC4gIEluIGl0cyBjdXJyZW50IGZvcm0sIHRoZSBkcmFmdCBzcGVjaWZpZXMgdGhh dCBhIFJSUkkgUmVxdWVzdCBjb250YWlucyBhIFVSTCB0byB0aGUgbWV0YWRhdGEgb2JqZWN0IGFz c29jaWF0ZWQgd2l0aCB0aGUgIFVBIHJlcXVlc3QuIEl0IG1pZ2h0IGJlIHVzZWZ1bCB0byBhbGxv dyBhIGRDRE4gdG8gcmVwbHkgd2l0aCBhIFJSUkkgUmVzcG9uc2UgaW5kaWNhdGluZyB0aGF0IGEg cGFydGljdWxhciByZXBseSBpcyB2YWxpZCBmb3IgYSBwYXJ0aWN1bGFyIHNldCBvZiBDRE5JIE1l dGFkYXRhIChub3QgbmVjZXNzYXJpbHkgYmVpbmcgdGhlIHNhbWUgc2V0IHJlZmVyZW5jZWQgYnkg dGhlIHVDRE4pLiBTdWNoIGEgZmVhdHVyZSB3b3VsZCBiZSBwYXJ0aWN1bGFybHkgdXNlZnVsIGlu IEhBUyBzY2VuYXJpb3MsIHdoZXJlIHdpdGggdGhlIGN1cnJlbnQgZHJhZnQgeW91IHdvdWxkIGhh dmUgaHVuZHJlZHMgb2YgUlJSSSBSZXF1ZXN0IGZvciBlYWNoIGluZGl2aWR1YWwgc2VnbWVudC4g DQpbWXVuZmVpXSBJdCBzZWVtcyB0byBtYWtlIHNlbnNlIGluIHRoZSBhYm92ZSBleGFtcGxlIHRv IHN1cHBvcnQgdGhlIGNvbm5lY3Rpb25zIHdpdGggdGhlIG1ldGFkYXRhIGludGVyZmFjZSBmb3Ig UlJSSSBpbiBIQVMgY2FzZS5JIGRpZG4ndCBhdHRlbmQgbGFzdCBJRVRGLHNvIEkgYW0gbm90IGNs ZWFyIG9mIHRoZSBjdXJyZW50IHN0YXR1cyBhbmQgY29uY2x1c2lvbiBvZiBIQVMgaW4gQ0ROSS4g RG9lcyBDRE5JIGNvbnNpZGVyIHRoZSBIQVMgY2FzZSBpbiBjdXJyZW50IHN0YWdlPyANCkl0IG1p Z2h0IGJlIHVzZWZ1bCB0byBpbmNsdWRlIGluIHRoZSBkcmFmdCBhIHNob3J0IG5vdGUgb3IgY29t bWVudCB0aGF0IGRpc2N1c3NlcyBieXRlIHJhbmdlIHJlcXVlc3RzIGFuZCBob3cgdGhpcyBpcyBk ZWFsdCB3aXRoIGJ5IHRoZSBSUlJJIGludGVyZmFjZS4gDQoNCkJlc3QgcmVnYXJkcywNCg0KUmF5 DQoNClRoaXMgZS1tYWlsIGFuZCBpdHMgY29udGVudHMgYXJlIHN1YmplY3QgdG8gdGhlIERJU0NM QUlNRVIgYXQgaHR0cDovL3d3dy50bm8ubmwvZW1haWxkaXNjbGFpbWVy ------=_001_NextPart465168505386_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi Ray=A3=AC
    Pls see inline. Thanks.
 
BR
Yunfei
 
zhangyunfei
 
Date: 2013-01-29 18:23
To: d= raft-he-cdni-routing-request-redirection@tools.ietf.org
CC: cdni@ietf.org
Subject: [CDNi] Questions related to=20 draft-he-cdni-routing-request-redirection-03
Hi,
 
I=A1=AFve reviewed draft-he-cdni-routing-request-redirection-03 and h= ave some=20 questions/comments:
 
  • Up until the protocol definition section, the draft makes the distin= ction=20 between DNS and HTTP-based redirection. Would it be safe to say that =A1= =AEHTTP=A1=AF in=20 this case is merely the primary example of =A1=AEmedia delivery protocol= =A1=AF? In other=20 words, would it be possible to replace HTTP here with any delivery proto= col=20 that includes a redirect message (e.g. RTMP, RTSP, etc). If this is the = case,=20 than it might be useful to mention this early on in the draft. =20
  • In section 4.2 it is stated that for HTTP redirection, it should be=20 possible for the uCDN to indicate whether it would like the dCDN to retu= rn an=20 IP address or hostname to redirect to. Why is this necessary? Especially= =20 considering the fact that the draft defines that the HTTP response to th= e UA=20 is being sent to the uCDN in encapsulated form, this shouldn=A1=AFt matt= er right?
  • In section 5, bullet 4) it says =A1=AEThe RR system of CDN B sends= =A1=AD=A1=AF, this=20 should probably read =A1=AEThe RR system of CDN A sends=A1=AD=A1=AF
  • How does the draft relate to work currently being done on the Metada= ta=20 interface? Particularly in dealing with multiple files being described b= y the=20 same (or higher level) metadata object.  In its current form, the d= raft=20 specifies that a RRRI Request contains a URL to the metadata object asso= ciated=20 with the  UA request. It might be useful to allow a dCDN to reply w= ith a=20 RRRI Response indicating that a particular reply is valid for a particul= ar set=20 of CDNI Metadata (not necessarily being the same set referenced by the u= CDN).=20 Such a feature would be particularly useful in HAS scenarios, where with= the=20 current draft you would have hundreds of RRRI Request for each individua= l=20 segment.
    <= I>[Yunfei] It seems=20 to make sense in the above example to support the connections with=20 the metadata interface for RRRI in HAS case.I didn't atte= nd=20 last IETF,so I am not clear of the current status and conclusion of HAS = in=20 CDNI. Does CDNI consider the HAS case in current stage?=20
    It might be useful to include in the draft a short not= e or=20 comment that discusses byte range requests and how this is dealt with by= the=20 RRRI interface.
 
Best regards,
 
Ray
 

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

------=_001_NextPart465168505386_=------ From ben@niven-jenkins.co.uk Wed Jan 30 00:55:39 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1955B21F88C7 for ; Wed, 30 Jan 2013 00:55:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.759 X-Spam-Level: X-Spam-Status: No, score=-100.759 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_31=0.6, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxlVMRTZqxjm for ; Wed, 30 Jan 2013 00:55:38 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 3DED921F8691 for ; Wed, 30 Jan 2013 00:55:37 -0800 (PST) Received: from [122.212.234.130] (helo=[172.40.1.145]) by mail4.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1U0TSA-0003s8-Jt; Wed, 30 Jan 2013 08:55:36 +0000 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: Date: Wed, 30 Jan 2013 08:55:28 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <327F5471-8910-4EC9-9A3A-927729ED06C6@niven-jenkins.co.uk> References: To: "Brandenburg, R. (Ray) van" X-Mailer: Apple Mail (2.1085) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "cdni@ietf.org" , "draft-he-cdni-routing-request-redirection@tools.ietf.org" Subject: Re: [CDNi] Questions related to draft-he-cdni-routing-request-redirection-03 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 08:55:39 -0000 Ray, Thanks for the comments/questions, please see inline 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: > =20 > - 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. =20 Yes & no. =46rom 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). =46rom 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 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? 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. =20 > - 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 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.=20 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.=20 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 > =20 > Best regards, > =20 > Ray > =20 > This e-mail and its contents are subject to the DISCLAIMER at = http://www.tno.nl/emaildisclaimer >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From ray.vanbrandenburg@tno.nl Wed Jan 30 01:23:33 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC9F21F886B for ; Wed, 30 Jan 2013 01:23:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.416 X-Spam-Level: X-Spam-Status: No, score=0.416 tagged_above=-999 required=5 tests=[AWL=-0.920, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_31=0.6, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfZrgUyQOTxm for ; Wed, 30 Jan 2013 01:23:32 -0800 (PST) Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE1521F8792 for ; Wed, 30 Jan 2013 01:23:31 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,566,1355094000"; d="scan'208";a="606836" Received: from unknown (HELO mail.tno.nl) ([134.221.225.221]) by mailhost1b.tno.nl with ESMTP; 30 Jan 2013 10:23:29 +0100 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.230]) by EXC-CASHUB02.tsn.tno.nl ([134.221.225.221]) with mapi id 14.02.0318.004; Wed, 30 Jan 2013 10:23:29 +0100 From: "Brandenburg, R. (Ray) van" To: Ben Niven-Jenkins Thread-Topic: [CDNi] Questions related to draft-he-cdni-routing-request-redirection-03 Thread-Index: Ac3+CyCOfZBkCVayTgyIK1hc6aa1UQAtAqcAAAKbCmA= Date: Wed, 30 Jan 2013 09:23:28 +0000 Message-ID: References: <327F5471-8910-4EC9-9A3A-927729ED06C6@niven-jenkins.co.uk> In-Reply-To: <327F5471-8910-4EC9-9A3A-927729ED06C6@niven-jenkins.co.uk> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.153] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" , "draft-he-cdni-routing-request-redirection@tools.ietf.org" Subject: Re: [CDNi] Questions related to draft-he-cdni-routing-request-redirection-03 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 09:23:33 -0000 Hi Ben, See inline. Ray -----Original Message----- From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk]=20 Sent: woensdag 30 januari 2013 9:55 To: Brandenburg, R. (Ray) van Cc: draft-he-cdni-routing-request-redirection@tools.ietf.org; cdni@ietf.org Subject: Re: [CDNi] Questions related to draft-he-cdni-routing-request-redi= rection-03 Ray, Thanks for the comments/questions, please see inline 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: > =20 > - Up until the protocol definition section, the draft makes the distincti= on between DNS and HTTP-based redirection. Would it be safe to say that 'HT= TP' 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 delive= ry protocol that includes a redirect message (e.g. RTMP, RTSP, etc). If thi= s is the case, than it might be useful to mention this early on in the draf= t. =20 Yes & no. From an abstract point of view HTTP is merely an example of a 'me= dia delivery protocol' (but is the only one that the WG is focussed on in t= he short term IIRC). >From a specific protocol point of view what needs to be in the messages wil= l likely vary by application protocol - e.g. RTMP has the concept of a stre= amname we'd need to communicate so can;t just re-use what we have defined s= o far for HTTP as-is but could use something extremely similar. The draft should probably more clearly differentiate between when we're tal= king about "application level redirection" at an abstract level versus HTTP= as a specific "application protocol" the request routing interface is defi= ning support for. > - In section 4.2 it is stated that for HTTP redirection, it should be pos= sible 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 co= nsidering 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= ? The original thinking was a uCDN may prefer IP address over hostname to sav= e 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. [Ray] Seems we agree on this point. =20 > - In section 5, bullet 4) it says 'The RR system of CDN B sends.', this s= hould 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 IET= F). > - How does the draft relate to work currently being done on the Metadata = interface? Particularly in dealing with multiple files being described by t= he same (or higher level) metadata object. In its current form, the draft = specifies that a RRRI Request contains a URL to the metadata object associa= ted 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 particula= r set of CDNI Metadata (not necessarily being the same set referenced by th= e uCDN). Such a feature would be particularly useful in HAS scenarios, wher= e with the current draft you would have hundreds of RRRI Request for each i= ndividual segment.=20 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 le= vel and not the path level in CDNI metadata. Allowing the dCDN to specify a scope against which the RRRI response applie= s is something we've already included. If we want to extend the current sco= pe 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 RRR= I 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 speci= fic 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 per= fectly 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 d= CDN to reply with: 'Ok, here you go with the redirect response for this par= ticular segment, and by the way, if you have any requests for segments asso= ciated with this one (indicated by metadata), you can also redirect them to= me'. > - 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 inter= face.=20 Byte range requests are independent of request routing, or are you suggesti= ng 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 wo= uld 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 reques= t. So let's say the UA sends a request to the uCDN for a particular file wi= th 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 r= eplies with a RRRI Response. The question is what the scope of the RRRI Req= uest and Response should be, is the scope limited to that particular byte r= ange, 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 range= s for that particular file? I'm not suggesting that we need any new functio= nality, I just think some definition of scope with regards to byte ranges a= nd RRRI could be helpful.=20 Ben > =20 > Best regards, > =20 > Ray > =20 > This e-mail and its contents are subject to the DISCLAIMER at http://www.= tno.nl/emaildisclaimer >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni