Re: [decade] follow up the meeting

["Woundy, Richard" <[e-mail]>]

<again not speaking as the chair>

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.

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

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

-- Rich

-----Original Message-----
From: Dirk Kutscher [mailto:[e-mail]] 
Sent: Thursday, September 09, 2010 9:53 AM
To: Song Haibin; 'Börje Ohlman'; Woundy, Richard; 'David A. Bryan'
Cc: [e-mail]; '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:[e-mail]]
> Sent: Thursday, September 09, 2010 5:49 AM
> To: 'Börje Ohlman'; 'Woundy, Richard'; 'David A. Bryan'
> Cc: [e-mail]; '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: [e-mail] [mailto:[e-mail]] On
> > Behalf Of B?rje Ohlman
> > Sent: Thursday, September 09, 2010 4:37 AM
> > To: Woundy, Richard; David A. Bryan
> > Cc: [e-mail]; 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: [e-mail] [mailto:[e-mail]] On
> > Behalf
> > > Of David A. Bryan
> > > Sent: Tuesday, September 07, 2010 9:37 AM
> > > To: Dirk Kutscher
> > > Cc: [e-mail]; 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<[e-mail]>
> > > 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: [e-mail] [mailto:[e-mail]] On
> > >>> Behalf Of Haibin Song
> > >>> Sent: Wednesday, August 04, 2010 9:03 PM
> > >>> To: [e-mail]
> > >>> 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
> > >> [e-mail]
> > >> https://www.ietf.org/mailman/listinfo/decade
> > >>
> > > _______________________________________________
> > > decade mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/decade
> > > _______________________________________________
> > > decade mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/decade
> >
> > _______________________________________________
> > decade mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/decade
>