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