Re: [decade] follow up the meeting
Dirk Kutscher <Dirk.Kutscher@neclab.eu> Thu, 09 September 2010 16:04 UTC
Return-Path: <Dirk.Kutscher@neclab.eu>
X-Original-To: decade@core3.amsl.com
Delivered-To: decade@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F10AA3A6914 for <decade@core3.amsl.com>; Thu, 9 Sep 2010 09:04:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.569
X-Spam-Level:
X-Spam-Status: No, score=-1.569 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeJ3AT4O2x9X for <decade@core3.amsl.com>; Thu, 9 Sep 2010 09:04:23 -0700 (PDT)
Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 60EF43A68D2 for <decade@ietf.org>; Thu, 9 Sep 2010 09:04:22 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id A01F32C0001B8; Thu, 9 Sep 2010 18:04:49 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office.hd)
Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOMrRvwi2fGV; Thu, 9 Sep 2010 18:04:49 +0200 (CEST)
Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.neclab.eu (Postfix) with ESMTP id 7C5692C0001B0; Thu, 9 Sep 2010 18:04:19 +0200 (CEST)
Received: from PALLENE.office.hd ([169.254.1.219]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0218.012; Thu, 9 Sep 2010 18:03:03 +0200
From: Dirk Kutscher <Dirk.Kutscher@neclab.eu>
To: "Woundy, Richard" <Richard_Woundy@cable.comcast.com>, Song Haibin <melodysong@huawei.com>, Börje Ohlman <Borje.Ohlman@ericsson.com>, "David A. Bryan" <dbryan@ethernot.org>
Thread-Topic: [decade] follow up the meeting
Thread-Index: Acs0B3nPmEYKVCd5Ta6ML+l3+6SKSQagR4Yw///w4gCAAKgpAIABX2oAgAB4rgD//58ncP/+xyYQ//2I9wD/+w3IwP/2Fh2Q
Date: Thu, 09 Sep 2010 16:03:01 +0000
Message-ID: <82AB329A76E2484D934BBCA77E9F524955EC08@PALLENE.office.hd>
References: <4c59b980.d37b0e0a.3dc6.ffffbdf0@mx.google.com> <82AB329A76E2484D934BBCA77E9F524954E197@PALLENE.office.hd> <AANLkTinpdZLvoqf-0YeAzPL0mHL9doajEfsvEcQuJ0sx@mail.gmail.com> <EE00404438E9444D90AEA84210DC406701B54F94@pacdcexcmb05.cable.comcast.com> <4C87F3EC.1080706@ericsson.com> <00be01cb4fd1$eddbdf40$c9939dc0$@com> <82AB329A76E2484D934BBCA77E9F524955EA3E@PALLENE.office.hd> <EE00404438E9444D90AEA84210DC406701BE5D4A@pacdcexcmb05.cable.comcast.com> <82AB329A76E2484D934BBCA77E9F524955EB0E@PALLENE.office.hd> <EE00404438E9444D90AEA84210DC406701BE5D87@pacdcexcmb05.cable.comcast.com>
In-Reply-To: <EE00404438E9444D90AEA84210DC406701BE5D87@pacdcexcmb05.cable.comcast.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.1.2.207]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "decade@ietf.org" <decade@ietf.org>, Haibin Song <haibinsong.cn@gmail.com>
Subject: Re: [decade] follow up the meeting
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" <decade.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/decade>, <mailto:decade-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/decade>
List-Post: <mailto:decade@ietf.org>
List-Help: <mailto:decade-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/decade>, <mailto:decade-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Sep 2010 16:04:25 -0000
> >In such a use case, the media server would access in-network storage > using DECADE. > > Right, but what are the benefits of using DECADE for unicast-only non- > P2P distribution? IMO, it really similar to P2P-CDN hybrid -- you would use standardized interfaces to store and access content on the content servers. You don't use P2P for the distribution, but unicast/multicast RTP (or eventually a download mechanism). I agree that you don't have efficiency improvements on the uplink as the in the other example -- so the main advantage would be on the operational side: having one standardized mechanisms for accessing in-network storage. This does not necessarily have to lead to new requirements. Best regards, Dirk > -----Original Message----- > From: Dirk Kutscher [mailto:Dirk.Kutscher@neclab.eu] > Sent: Thursday, September 09, 2010 11:06 AM > To: Woundy, Richard; Song Haibin; Börje Ohlman; David A. Bryan > Cc: decade@ietf.org; Haibin Song > Subject: RE: [decade] follow up the meeting > > > I think I understand the DECADE use case for a P2P-CDN hybrid, which > > might possibly be leveraged for "integrating CDN elements into the > > TISPAN IPTV architecture". But I'm not quite certain I understand the > > DECADE use case for unicast-only, non-P2P distribution. > > In such a use case, the media server would access in-network storage > using DECADE. > > > >The basic idea is to marry the existing IMS (or integrated) > > architecture with in-network storage, including functions such as > > selecting caches based on network metrics, available content, > policies > > etc. > > > > Cache selection would seem to be more in scope for ALTO than DECADE. > > Have you looked at this draft: > <http://datatracker.ietf.org/doc/draft- > > penno-alto-cdn/>? > > Yes, the selection is not DECADE-relevant. > > > >The content distribution to the CDN nodes themselves could again > > leverage P2P -- depending on the implementation of the CDN. > > > > This sounds like the P2P-CDN hybrid use case again. > > Yes, possibly. > > > Best regards, > > Dirk > > > > > -- Rich > > > > -----Original Message----- > > From: Dirk Kutscher [mailto:Dirk.Kutscher@neclab.eu] > > Sent: Thursday, September 09, 2010 9:53 AM > > To: Song Haibin; 'Börje Ohlman'; Woundy, Richard; 'David A. Bryan' > > Cc: decade@ietf.org; 'Haibin Song' > > Subject: RE: [decade] follow up the meeting > > > > Thanks for the feedback so far. I guess we don't need to argue about > > P2P vs. direct download importance. My point was more that we really > > should consider different distribution approaches. It's indisputable > > that P2P is here to stay and will essentially be needed to deal with > > future mass content distribution bandwidth requirements. > > > > The hybrid scenario that Boerje described is a valid IPTV scenario > > instance IMO. > > > > I was also thinking about the current ETSI TSIPAN work on integrating > > CDN elements into the TISPAN IPTV architecture [1] (perhaps this has > > been brought up before). > > The basic idea is to marry the existing IMS (or integrated) > > architecture with in-network storage, including functions such as > > selecting caches based on network metrics, available content, > policies > > etc. The actual delivery to the user would use existing TISPAN- > defined > > mechanisms, e.g., RTP-based unicast/multicast streaming or download, > > but a media delivery function would need interfaces to in-network > > storage accessing the content. The content distribution to the CDN > > nodes themselves could again leverage P2P -- depending on the > > implementation of the CDN. > > > > We would need to analyze it in more detail, but to me it really seems > > applicable to our objective for DECADE. > > > > > > Best regards, > > > > Dirk > > > > > > > > [1] > > http://docbox.etsi.org/TISPAN/Open/NGN_LATEST_DRAFTS/RELEASE3/02076- > > ngn-r3v027.pdf > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: Song Haibin [mailto:melodysong@huawei.com] > > > Sent: Thursday, September 09, 2010 5:49 AM > > > To: 'Börje Ohlman'; 'Woundy, Richard'; 'David A. Bryan' > > > Cc: decade@ietf.org; 'Haibin Song'; Dirk Kutscher > > > Subject: RE: [decade] follow up the meeting > > > > > > Hi Borje, > > > > > > I think this makes a lot of sense. And in the IPTV use case you > > talked > > > about, DECADE can provide open access to different content > providers > > > for > > > putting their contents to the in-network storage (under the > > > administration > > > of the central server) and serving the DECADE-compatible STBs (also > > > require > > > the STB to understand the data format). > > > > > > I also agree that the hybrid architecture is good and can also save > > the > > > load > > > on the central server. > > > > > > I do not agree with the statement that P2P traffic is declining as > > the > > > reasons have been said by Yunfei and David. As video is evolving to > > HD, > > > its > > > traffic has contributed to a large fraction of the Internet traffic, > > > but a > > > relative proportion of it is engined by peer to peer technique. And > > > most > > > websites in China cooperate with Thunder to accelerate the file > > > download. > > > > > > Xie Xie, > > > Haibin (as a contributor) > > > > > > > -----Original Message----- > > > > From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On > > > > Behalf Of B?rje Ohlman > > > > Sent: Thursday, September 09, 2010 4:37 AM > > > > To: Woundy, Richard; David A. Bryan > > > > Cc: decade@ietf.org; Haibin Song; Dirk Kutscher > > > > Subject: Re: [decade] follow up the meeting > > > > > > > > To elaborate a bit on the IPTV use case. Let's assume an IPTV > > > > distribution service that is a hybrid between traditional CDN and > a > > > p2p > > > > service (as I understand it BBC has implemented something like > > that). > > > > Such a service would distribute content from central servers, > make > > > use > > > > of CDN caches on the way and finally use the end hosts/STB as > > caches > > > for > > > > the p2p part of the application. If we only let the p2p > application > > > in > > > > the host/STB store content in the DECADE storage the content > first > > > have > > > > to be downloaded from the IPTV server/CDN cache over the access > > link > > > to > > > > the host/STB and then uploaded, over the same access link, to the > > > DECADE > > > > storage before any peer in p2p part of the application can get > from > > > the > > > > DECADE storage instead of getting it from the client. To me it > > seems > > > to > > > > make a lot of sense if the DECADE storage could 'cache' the > content > > > when > > > > the first download to the host/STB is done. That would mean the > > > content > > > > never have to travel over the weak uplink. For this to be > feasible, > > > one > > > > requirement that would be needed is that the IPTV service can > > prompt > > > the > > > > DECADE storage that certain content should be cached on its way > to > > > the > > > > host. > > > > Having such functionality, as David points out, that allows a > host > > to > > > to > > > > get content from the DECADE storage of neighbouring host rather > > from > > > a > > > > central server, would of course also offload the core network in > > the > > > > same way a traditional CDN does. > > > > > > > > Hope this helps, let me know otherwise. > > > > > > > > Börje > > > > > > > > On 2010-09-08 01:39, Woundy, Richard wrote: > > > > > (not wearing my chair's hat) > > > > > > > > > > I agree with David Bryan's points below. > > > > > > > > > > For the IPTV application, can you help me understand how the > > > intended > > > > > use of DECADE differs from the use of a typical content > delivery > > > network > > > > > (CDN)? > > > > > > > > > >> Standardized interfaces to in-network storage could provide a > > real > > > > > benefit for ISPs and operator to reduce the load on access and > > core > > > > > networks... > > > > > > > > > > Can you describe how DECADE would reduce the IPTV traffic load > on > > > > access > > > > > and core networks? > > > > > > > > > > For the P2P case, DECADE would offload P2P traffic from the > peer > > to > > > its > > > > > in-network storage, which reduces the P2P traffic load on the > > > access > > > > > network uplink. Do you do something similar for IPTV? > > > > > > > > > > I'm sorry if the answers are obvious. I don't intend these > > > questions to > > > > > preclude any IPTV/DECADE discussion, but it would help me > > > understand the > > > > > IPTV example better. > > > > > > > > > > -- Rich > > > > > > > > > > -----Original Message----- > > > > > From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] > On > > > > Behalf > > > > > Of David A. Bryan > > > > > Sent: Tuesday, September 07, 2010 9:37 AM > > > > > To: Dirk Kutscher > > > > > Cc: decade@ietf.org; Haibin Song > > > > > Subject: Re: [decade] follow up the meeting > > > > > > > > > > While I am keen on keeping scope as narrow as possible (hence > my > > > > > opposition to expanding the use cases too much), if we are > going > > to > > > > > pick one, IPTV (in particular IPTV that obtains information > from > > > other > > > > > clients, so is actually somewhat peer-to-peer anyway) would > seem > > to > > > be > > > > > the logical candidate. > > > > > > > > > > To keep the scope reasonable, I'd want to hear a bit more about > > how > > > > > decade would be used in this context (i.e., I hope with data > user > > A > > > > > requests being stored in the decade box and then user B > obtaining > > > from > > > > > it, not simply as a remote file store for content from the > > service > > > > > provider "juke box" style), but if we are going to expand the > > scope, > > > > > and we are reusing decade in a way that is consistent with a > > narrow > > > > > scope, using decade between set top boxes seems like as > > reasonable > > > an > > > > > additional use case as we could propose. > > > > > > > > > > BTW there has been a bunch of discussion about the discussion > > that > > > P2P > > > > > (or Web, or pretty much anything else on the internet) is > somehow > > > > > dying and video is dominating everything. Most of this is > > > (including, > > > > > I'll go on a limb and say, the talk from the plenary) coming > from > > a > > > > > misunderstanding of absolute vs. relative growth. I.e., using > > > > > percentages instead of absolute numbers. Video traffic is > growing > > > > > simply because the bandwidth of it is very large, and appears > to > > be > > > > > dominated by YouTube (and much of what was once P2P content > > moving > > > > to > > > > > YouTube) and other video sharing services, not video > > communications, > > > > > IPTV, etc. There was a good debunking of the relative approach > > > shown > > > > > in the plenary slides (and a similar Wired article recently) > > here: > > > > > > > > > > > > > > http://www.boingboing.net/2010/08/17/is-the-web-really- > > > de.html?utm_sou > > > > rc > > > > > > > > > e=feedburner&utm_medium=feed&utm_campaign=Feed%3A+boingboing%2 > > > > FiBag+(Boi > > > > > ng+Boing) > > > > > > > > > > This makes it clear that while the fact video is growing is > very > > > > > important and something we need to be aware of (particularly > for > > > > > bandwidth use), it does not imply P2P (or web) traffic is > > actually > > > > > declining. In absolute traffic, it appears it is not (from the > > > wired > > > > > data...not really sure about the plenary since I don't have the > > raw > > > > > data). > > > > > > > > > > David > > > > > > > > > > On Tue, Sep 7, 2010 at 8:55 AM, Dirk > > > Kutscher<Dirk.Kutscher@neclab.eu> > > > > > wrote: > > > > >> Hi Haibin and all, > > > > >> > > > > >> Following up on this, I agree that a concrete example for > > another > > > > > typical application that could benefit from in-network storage > > > would be > > > > > useful. > > > > >> I would like to propose IPTV as an application and would > suggest > > > > > spending some work on analyzing its requirements regarding > > DECADE: > > > > >> 1) IPTV and video download is an important application already. > > > IPTV > > > > > contributes significantly to overall inter-domain and intra- > > domain > > > > > traffic volume. In fact, according to [1], video is the fastest > > > growing > > > > > application (Internet-traffic-wise) -- and P2P is the fastest > > > declining. > > > > >> 2) Currently, there are different products and service > offerings > > > with > > > > > their individual distribution and caching systems, and there > are > > > more to > > > > > come (see recent product launches and announcements from > popular > > > > vendors > > > > > and 'over-the-top' service providers). > > > > >> 3) Standardized interfaces to in-network storage could provide > a > > > real > > > > > benefit for ISPs and operator to reduce the load on access and > > core > > > > > networks and to enhance quality of experience for customers. > > > > >> In summary, IPTV is an important existing application that > > > provides > > > > > in-network-storage requirements, potentially similar to P2P > > > > > applications, that we should look at. > > > > >> Let me know what you think! > > > > >> > > > > >> Thanks, > > > > >> > > > > >> Dirk > > > > >> > > > > >> > > > > >> > > > > >> [1] http://www.ietf.org/proceedings/77/slides/plenaryt-4.pdf > > > > >> > > > > >> > > > > >> > > > > >> -- > > > > >> NEC Laboratories Europe > > > > >> > > > > >> NEC Europe Limited | Registered Office: NEC House, 1 Victoria > > Road, > > > > > London W3 6BL | Registered in England 2832014 > > > > >> > > > > >>> -----Original Message----- > > > > >>> From: decade-bounces@ietf.org [mailto:decade- > bounces@ietf.org] > > On > > > > >>> Behalf Of Haibin Song > > > > >>> Sent: Wednesday, August 04, 2010 9:03 PM > > > > >>> To: decade@ietf.org > > > > >>> Subject: [decade] follow up the meeting > > > > >>> > > > > >>> Hi Folks, > > > > >>> > > > > >>> > > > > >>> > > > > >>> Some topics were discussed a lot during the meeting , and > they > > > may > > > > > need > > > > >>> further discussion in the list to make it clearer. One of > them > > is > > > the > > > > >>> following: > > > > >>> > > > > >>> > > > > >>> > > > > >>> The requirement to support another typical application other > > than > > > > > P2P, > > > > >>> I believe this is a high level requirement. And talking about > a > > > > >>> concrete example is more helpful. But the detailed > requirements > > > might > > > > >>> be similar to P2P applications. > > > > >>> > > > > >>> > > > > >>> > > > > >>> I would like to see more discussion about it in the list. > > > > >>> > > > > >>> > > > > >>> > > > > >>> BR, > > > > >>> > > > > >>> Haibin > > > > >>> > > > > >>> > > > > >> _______________________________________________ > > > > >> decade mailing list > > > > >> decade@ietf.org > > > > >> https://www.ietf.org/mailman/listinfo/decade > > > > >> > > > > > _______________________________________________ > > > > > decade mailing list > > > > > decade@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/decade > > > > > _______________________________________________ > > > > > decade mailing list > > > > > decade@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/decade > > > > > > > > _______________________________________________ > > > > decade mailing list > > > > decade@ietf.org > > > > https://www.ietf.org/mailman/listinfo/decade > > >
- [decade] follow up the meeting Haibin Song
- Re: [decade] follow up the meeting Dirk Kutscher
- Re: [decade] follow up the meeting David A. Bryan
- Re: [decade] follow up the meeting Woundy, Richard
- Re: [decade] follow up the meeting zhangyunfei
- Re: [decade] follow up the meeting Börje Ohlman
- Re: [decade] follow up the meeting Woundy, Richard
- Re: [decade] follow up the meeting Song Haibin
- Re: [decade] follow up the meeting Dirk Kutscher
- Re: [decade] follow up the meeting Woundy, Richard
- Re: [decade] follow up the meeting Dirk Kutscher
- Re: [decade] follow up the meeting Woundy, Richard
- Re: [decade] follow up the meeting Dirk Kutscher