Re: [decade] follow up the meeting

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

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

Right, but what are the benefits of using DECADE for unicast-only non-P2P distribution?

I'm looking for an explanation similar to what Borje provided for the P2P-CDN use case.

-- Rich

-----Original Message-----
From: Dirk Kutscher [mailto:[e-mail]] 
Sent: Thursday, September 09, 2010 11:06 AM
To: Woundy, Richard; Song Haibin; Börje Ohlman; David A. Bryan
Cc: [e-mail]; 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:[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
> >