Subject: [decade] Comments on draft-song-decade-problem-statement

From: Francois Le Faucheur <[email-masked]>
Date: Fri, 20 Nov 2009 15:28:07 +0100

Hello,

Here are some comments/suggestions re decade-problem-statement:

* section 3.1:
"Recently, the IETF Application Layer Traffic Optimization (ALTO) Working Group is formed to provide P2P applications with network information so that they can perform better-than-random initial peer selection [I-D.ietf-alto-problem-statement]. "
I believe ALTO can be used for peer selection at any time (ie not just initially).
The information provided by ALTO is not necessarily "network information" (e.g. could be just a list of selected peers).
Also, some P2P Apps use other criteria than pure random, but still not necessarily optimal.
So how about, something like:
"The IETF Application Layer Traffic Optimization (ALTO) Working Group specifies mechanisms that allow P2P applications to perform selection of peers that is superior to random selection or selection based on information deducted from partial observation [I-D.ietf-alto-problem-statement]. "

* section 3.1:
"On the other hand, it is reported that P2P traffic is becoming the dominating traffic on the access networks of some networks, reaching as high as 50-60% at the down-links and 60-90% at the uplinks ([DCIA], [ICNP], [ipoque.P2P_survey.], [P2P_file_sharing]).  Consequently, it becomes increasingly important to complement the ALTO effort and reduce upload access traffic, in addition to cross-domain and backbone traffic.
"
I think it would be worth discussing how LEDBAT relates to the above.
Perhaps adding something along the lines of:
" The IETF Low Extra Delay Background Transport (LEDBAT) Working Group is focusing on broadly applicable techniques that allow large amounts of data to be consistently transmitted without substantially affecting the delays experienced by other users and applications. It is expected that some P2P applications would start using such techniques, thereby somewhat alleviating the perceivable impact (at least on other applications) of their high volume traffic . However, such techniques do not remove all inefficiencies, such as those associated with traffic being sent upstream as many times as there are remote peers interested in getting the corresponding information."

* section 3.1:
The current text discusses inefficiencies in terms of access network bandwidth being effectively wasted from the viewpoint of the network operator. Perhaps it would also be worth making explicit the consequences from the P2P applications viewpoint i.e. likely longer time to retrieve complete content as well as likely higher latency for some real time applications (e.g. PPSP).

* section 4:
"Note that DECADE is independent of current IETF work on P2P, e.g. P2PSIP, ALTO, PPSP.  For example, peers discovered by either RELOAD or ALTO can all use DECADE to share data.  DECADE will focus on the  problems of P2P applications, although the solution might be used in other context."

The relationship between DECADE and PPSP deserves clarification. In particular, because the PP2P problem statement document (draft-zhang-ppsp-problem-statement-05):
	* in its section 4.2 : describes Edge Caches as one of the motivations for developing PPSP standards protocols
	* in its section 7.1 : describes a PPSP use case with in-network CDN nodes for enhanced P2P streaming.

I think DECADE and PP2P may both contribute independently, and possibly simultaneously, to making content available closer to peers. For example, I can picture the following situations for PPSP and DECADE coexistense:
	* a given network supports DECADE in-network caching, and its CDN nodes do not participate as PPSP Peers for a given "stream" (e.g. say because no CDN arrangement has been put in place between the Content Provider and the considered network provider). In that case, PPSP Peers will all be "off-net" but will be able to use DECADE in-network caching to exchange chunks. (*)
	* a given network does not support DECADE in-network caching, and (some of) its CDN nodes participate as PPSP Peers for a given "stream" (e.g. say because an arrangement has been put in place between the Content Provider and the considered network provider). In that case, the CDN nodes will participate as in-network PPSP Peers. The off-net PP2P Peers (ie endusers) will be able to get chunks from the in-network CDN nodes (using PP2P protocols with the CDN nodes).
	* a given network supports DECADE in-network caching, and (some of) its CDN nodes participate as PPSP Peers for a given "stream" (e.g. say because an arrangement has been put in place between the Content Provider and the considered network provider). In that case, the CDN nodes will participate as in-network PPSP Peers. The off-net PP2P Peers (ie endusers) will be able to get chunks from the in-network CDN nodes (using PP2P protocols with the CDN nodes)  _as well as_  be able to get chunks from DECADE in-network Caching populated (using DECADE protocols) by PPSP Peers (both off-net end-users and in-network CDN Nodes).

(For simplicity I discussed the use of DECADE and PPSP Peering in the same single network, but those could happen in different networks and same would apply).

(*) a particular case of that is when the Content Publisher behaves as a Peer and uses DECADE to populate in-network content as discussed in section 5.2 of DECADE problem statement.

Is this how you also see DECADE and PPSP relate? can this be explicitly discussed?

* section 4.2:
would be worth clarifying who controls the authorization. At least, one case is that authorization is controlled by the DECADE user that places the content in the cache.

* Figures 2, 3, 4 and 5:
I suggest you also illustrate the actual transfer of data (in addition to the DECADE requests). It is done in Fig 5 but not in previous ones. also I think it will make sequentiality clearer.
For example in Fig 2, the data transfer from Sb to B would not happen right after step 3 ("3 IAP get"); it would happen after a data transfer from Sa to Sb , which would happen after "4 IAP get" from Sb to Sa.

* Figure 4:
It may be more intuitive to swap the order of step 2 and 3 (ie show A storing the object in Sb before A responds to B).

Hope that helps.

Francois

---

From: Song Haibin <[email-masked]>
Date: Mon, 23 Nov 2009 11:11:56 +0800

Hi Francois,

Good comments. 

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of Francois Le Faucheur
>Sent: Friday, November 20, 2009 10:28 PM
>To: [email-masked]
>Subject: [decade] Comments on draft-song-decade-problem-statement
>
>Hello,
>
>"Recently, the IETF Application Layer Traffic Optimization 
>(ALTO) Working Group is formed to provide P2P applications 
>with network information so that they can perform 
>better-than-random initial peer selection 
>[I-D.ietf-alto-problem-statement]. "

It is in paragraph 4 of "Description of Working Group" in ALTO WG charter.
You are right that P2P applications can do the peer selection with the help
of ALTO server at any time. But  I think here "initial peer selection" means
it (ALTO) is the first step for peer selection, and after that P2P
application users can do another round of peer selection based on other
things, such like chunk availability(e.g. "rarest piece first") and per pair
connection quality.

>The information provided by ALTO is not necessarily "network 
>information" (e.g. could be just a list of selected peers).

The peer selection is mainly based on network cost information. But you are
right, we should delete the word "network" here.

>"The IETF Application Layer Traffic Optimization (ALTO) 
>Working Group specifies mechanisms that allow P2P applications 
>to perform selection of peers that is superior to random 
>selection or selection based on information deducted from 
>partial observation [I-D.ietf-alto-problem-statement]. "
>

It's okay. I prefer to just delete the word "network", just like what is
said in the ALTO charter.

>
>* section 3.1:
>"On the other hand, it is reported that P2P traffic is 
>becoming the dominating traffic on the access networks of some 
>networks, reaching as high as 50-60% at the down-links and 
>60-90% at the uplinks ([DCIA], [ICNP], [ipoque.P2P_survey.], 
>[P2P_file_sharing]).  Consequently, it becomes increasingly 
>important to complement the ALTO effort and reduce upload 
>access traffic, in addition to cross-domain and backbone traffic.
>"
>" The IETF Low Extra Delay Background Transport (LEDBAT) 
>Working Group is focusing on broadly applicable techniques 
>that allow large amounts of data to be consistently 
>transmitted without substantially affecting the delays 
>experienced by other users and applications. It is expected 
>that some P2P applications would start using such techniques, 
>thereby somewhat alleviating the perceivable impact (at least 
>on other applications) of their high volume traffic . However, 
>such techniques do not remove all inefficiencies, such as 
>those associated with traffic being sent upstream as many 
>times as there are remote peers interested in getting the 
>corresponding information."
>

I agree with what you said here. But LEDBAT is not so relevant to DECADE as
ALTO. ALTO can reduce the backbone traffic of ISP's network by do better
peer selection, while DECADE can save much of your uplink bandwidth by
putting your contents into network and allowing others to download from
there (need standard resource control). By putting the contents into
network, P2P applications can also improve the availability of the content.
LEDBAT focuses on the techniques that will alleviate the impact among
transport for different applications. It is a little different.

>
>* section 3.1:
>The current text discusses inefficiencies in terms of access 
>network bandwidth being effectively wasted from the viewpoint 
>of the network operator. Perhaps it would also be worth making 
>explicit the consequences from the P2P applications viewpoint 
>i.e. likely longer time to retrieve complete content as well 
>as likely higher latency for some real time applications (e.g. PPSP).
>

Good point. 

>* section 4:
>"Note that DECADE is independent of current IETF work on P2P, 
>e.g. P2PSIP, ALTO, PPSP.  For example, peers discovered by 
>either RELOAD or ALTO can all use DECADE to share data.  
>DECADE will focus on the  problems of P2P applications, 
>although the solution might be used in other context."
>
>The relationship between DECADE and PPSP deserves 
>clarification. In particular, because the PP2P problem 
>statement document (draft-zhang-ppsp-problem-statement-05):
>	* in its section 4.2 : describes Edge Caches as one of 
>the motivations for developing PPSP standards protocols
>	* in its section 7.1 : describes a PPSP use case with 
>in-network CDN nodes for enhanced P2P streaming.
>

DECADE is quite different from PPSP while then can collaborate in a system.
P2P streaming applications (e.g. those who use PPSP protocol) can use DECADE
to distribute their services. DECADE is more generic, and focues on the
standard interface between P2P client and the in-network storage(esp.
resource control). The purpose of existing P2P caches are good and they are
beneficial to both ISPs and P2P applications, but they have to support a lot
of on-evolving P2P application protocols. DECADE will allow P2P applications
users to use their in-network storage and share their in-network resources
in a standard way, so as to reduce the complexity of existing p2p cache and
allow better integration of p2p policies.

>I think DECADE and PP2P may both contribute independently, and 
>possibly simultaneously, to making content available closer to 
>peers. For example, I can picture the following situations for 
>PPSP and DECADE coexistense:
>	* a given network supports DECADE in-network caching, 
>and its CDN nodes do not participate as PPSP Peers for a given 
>"stream" (e.g. say because no CDN arrangement has been put in 
>place between the Content Provider and the considered network 
>provider). In that case, PPSP Peers will all be "off-net" but 
>will be able to use DECADE in-network caching to exchange chunks. (*)
>	* a given network does not support DECADE in-network 
>caching, and (some of) its CDN nodes participate as PPSP Peers 
>for a given "stream" (e.g. say because an arrangement has been 
>put in place between the Content Provider and the considered 
>network provider). In that case, the CDN nodes will 
>participate as in-network PPSP Peers. The off-net PP2P Peers 
>(ie endusers) will be able to get chunks from the in-network 
>CDN nodes (using PP2P protocols with the CDN nodes).
>	* a given network supports DECADE in-network caching, 
>and (some of) its CDN nodes participate as PPSP Peers for a 
>given "stream" (e.g. say because an arrangement has been put 
>in place between the Content Provider and the considered 
>network provider). In that case, the CDN nodes will 
>participate as in-network PPSP Peers. The off-net PP2P Peers 
>(ie endusers) will be able to get chunks from the in-network 
>CDN nodes (using PP2P protocols with the CDN nodes)  _as well 
>as_  be able to get chunks from DECADE in-network Caching 
>populated (using DECADE protocols) by PPSP Peers (both off-net 
>end-users and in-network CDN Nodes).
>
>(For simplicity I discussed the use of DECADE and PPSP Peering 
>in the same single network, but those could happen in 
>different networks and same would apply).
>
>(*) a particular case of that is when the Content Publisher 
>behaves as a Peer and uses DECADE to populate in-network 
>content as discussed in section 5.2 of DECADE problem statement.
>

Thank you for good examples: ) 

>Is this how you also see DECADE and PPSP relate? can this be 

We can regard PPSP as a specific protocol of a streaming application, which
could use DECADE just like other p2p applications.

>* section 4.2:
>would be worth clarifying who controls the authorization. At 
>least, one case is that authorization is controlled by the 
>DECADE user that places the content in the cache.
>

Yes. The user can authorize others to access "its" in-network storage.

>
>* Figures 2, 3, 4 and 5:
>I suggest you also illustrate the actual transfer of data (in 
>addition to the DECADE requests). It is done in Fig 5 but not 
>in previous ones. also I think it will make sequentiality clearer.
>For example in Fig 2, the data transfer from Sb to B would not 
>happen right after step 3 ("3 IAP get"); it would happen after 
>a data transfer from Sa to Sb , which would happen after "4 
>IAP get" from Sb to Sa.
>

We will add lines to illustrate the data transfer: )
 
>* Figure 4:
>It may be more intuitive to swap the order of step 2 and 3 (ie 
>show A storing the object in Sb before A responds to B).
>
It's a little tricky here and P2P applications can use different ways to do
it. When A gets the request to store object to Sb, it can simply reply with
"Okay", and then do the store operation. Also it can start to store the
object to Sb and then reply to B with a message " I have started to
transfer...".  

Thanks,
Haibin

>
>Hope that helps.
>
>Francois
>
>_______________________________________________
>decade mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/decade
>

---

From: "zhangyunfei" <[email-masked]>
Date: Mon, 23 Nov 2009 12:04:37 +0800

Hi,

    It seems great that Francois has given us a clearer picture on the usage of PPSP and DECADE.Thanks a lot.
    I would like to clarify that although both PPSP and DECADE have an edge caches usages, they have several noticeable differences:
    1)Motivation:
           PPSP, operator/ISP or other vendors to launch p2p streaming service; 
           DECADE, operator/ISP to decrease traffic pressure.The service is not run by opertor/ISP.
    2)Task: 
          PPSP,unifying peer/tracker protocols both for CDN and common peers. CDN as superpeers equipping PPSP protocols.PPSP protocols are   p2p protocols.
          DECADE,creating peer/non-peer client to CDN access protocol, which is not a P2P protocol itself. Peer/client needs to update to       support DECADE protocol.
   3)Scope: PPSP, p2p streaming senarios; DECADE, p2p data-intensive senarios;
   4)Purpose:
        PPSP:efficient information exchange between peers
        DECADE:peer/client and cache command to ask caches to perform corresponding actions
    In a word, PPSP and DECADE may occur in the same senario,p2p streaming while their functionalities are quite different.

BR
Yunfei

zhangyunfei
2009-11-23

发件人： Song Haibin
发送时间： 2009-11-23 11:19:32
收件人： 'Francois Le Faucheur'; [email-masked]
抄送： 
主题： Re: [decade] Comments on draft-song-decade-problem-statement

Hi  Francois,

Good  comments.  

Good  point.  

Thanks,
Haibin

---

From: Song Haibin <[email-masked]>
Date: Mon, 23 Nov 2009 15:26:02 +0800

Yunfei,

Thanks for your reply. I agree with your analysis here.
 
>           DECADE, operator/ISP to decrease traffic pressure.The service is
not run by opertor/ISP.

Reducing traffic, especially the last mile uplink is one important
motivation. I think here you use the word "service" to mean applications
actually.       
 
Haibin 

________________________________

From: zhangyunfei [mailto:[email-masked]] 
Sent: Monday, November 23, 2009 12:05 PM
To: Song Haibin; 'Francois Le Faucheur'; [email-masked]
Subject: Re: Re: [decade] Comments on draft-song-decade-problem-statement

	Hi,
	 
	    It seems great that Francois has given us a clearer picture on
the usage of PPSP and DECADE.Thanks a lot.
	    I would like to clarify that although both PPSP and DECADE have
an edge caches usages, they have several noticeable differences:
	    1)Motivation:
	           PPSP, operator/ISP or other vendors to launch p2p
streaming service; 
	           DECADE, operator/ISP to decrease traffic pressure.The
service is not run by opertor/ISP.

	 2)Task: 
	          PPSP,unifying peer/tracker protocols both for CDN and
common peers. CDN as superpeers equipping PPSP protocols.PPSP protocols are
p2p protocols.
	          DECADE,creating peer/non-peer client to CDN access
protocol, which is not a P2P protocol itself. Peer/client needs to update to
support DECADE protocol.
	   3)Scope: PPSP, p2p streaming senarios; DECADE, p2p data-intensive
senarios;
	   4)Purpose:
	        PPSP:efficient information exchange between peers
	        DECADE:peer/client and cache command to ask caches to
perform corresponding actions
	    In a word, PPSP and DECADE may occur in the same senario,p2p
streaming while their functionalities are quite different.
	 
	BR
	Yunfei
	 
	________________________________

		zhangyunfei
	2009-11-23
	________________________________

		发件人： Song Haibin
	 
		Hi  Francois,
	 
	Good  comments.  

	>I  believe  ALTO  can  be  used  for  peer  selection  at  any
time  (ie  
	>not  just  initially).
	 
	It  is  in  paragraph  4  of  "Description  of  Working  Group"  in
ALTO  WG  charter.
	You  are  right  that  P2P  applications  can  do  the  peer
selection  with  the  help
	of  ALTO  server  at  any  time.  But    I  think  here  "initial
peer  selection"  means
	it  (ALTO)  is  the  first  step  for  peer  selection,  and  after
that  P2P
	application  users  can  do  another  round  of  peer  selection
based  on  other
	things,  such  like  chunk  availability(e.g.  "rarest  piece
first")  and  per  pair
	connection  quality.
	 
	>information"  (e.g.  could  be  just  a  list  of  selected
peers).
	 
	The  peer  selection  is  mainly  based  on  network  cost
information.  But  you  are
	right,  we  should  delete  the  word  "network"  here.
	 
	>Also,  some  P2P  Apps  use  other  criteria  than  pure  random,
but  
	>still  not  necessarily  optimal.
	 
	It's  okay.  I  prefer  to  just  delete  the  word  "network",
just  like  what  is
	said  in  the  ALTO  charter.

	>corresponding  information."
	 
	I  agree  with  what  you  said  here.  But  LEDBAT  is  not  so
relevant  to  DECADE  as
	ALTO.  ALTO  can  reduce  the  backbone  traffic  of  ISP's  network
by  do  better
	peer  selection,  while  DECADE  can  save  much  of  your  uplink
bandwidth  by
	putting  your  contents  into  network  and  allowing  others  to
download  from
	there  (need  standard  resource  control).  By  putting  the
contents  into
	network,  P2P  applications  can  also  improve  the  availability
of  the  content.
	LEDBAT  focuses  on  the  techniques  that  will  alleviate  the
impact  among
	transport  for  different  applications.  It  is  a  little
different.

	Good  point.  

	>in-network  CDN  nodes  for  enhanced  P2P  streaming.
	 
	DECADE  is  quite  different  from  PPSP  while  then  can
collaborate  in  a  system.
	P2P  streaming  applications  (e.g.  those  who  use  PPSP
protocol)  can  use  DECADE
	to  distribute  their  services.  DECADE  is  more  generic,  and
focues  on  the
	standard  interface  between  P2P  client  and  the  in-network
storage(esp.
	resource  control).  The  purpose  of  existing  P2P  caches  are
good  and  they  are
	beneficial  to  both  ISPs  and  P2P  applications,  but  they  have
to  support  a  lot
	of  on-evolving  P2P  application  protocols.  DECADE  will  allow
P2P  applications
	users  to  use  their  in-network  storage  and  share  their
in-network  resources
	in  a  standard  way,  so  as  to  reduce  the  complexity  of
existing  p2p  cache  and
	allow  better  integration  of  p2p  policies.

	 

	>Is  this  how  you  also  see  DECADE  and  PPSP  relate?  can
this  be  
	>explicitly  discussed?
	 
	We  can  regard  PPSP  as  a  specific  protocol  of  a  streaming
application,  which
	could  use  DECADE  just  like  other  p2p  applications.

	>DECADE  user  that  places  the  content  in  the  cache.
	 
	Yes.  The  user  can  authorize  others  to  access  "its"
in-network  storage.

	 
	>show  A  storing  the  object  in  Sb  before  A  responds  to  B).
	It's  a  little  tricky  here  and  P2P  applications  can  use
different  ways  to  do
	it.  When  A  gets  the  request  to  store  object  to  Sb,  it
can  simply  reply  with
	"Okay",  and  then  do  the  store  operation.  Also  it  can  start
to  store  the
	object  to  Sb  and  then  reply  to  B  with  a  message  "  I
have  started  to
	transfer...".    

	Thanks,
	Haibin

---

From: "zhangyunfei" <[email-masked]>
Date: Mon, 23 Nov 2009 15:30:02 +0800

Sure.

BR
Yunfei

zhangyunfei
2009-11-23

发件人： Song Haibin
发送时间： 2009-11-23 15:33:20
收件人： 'zhangyunfei'; 'Francois Le Faucheur'; [email-masked]
抄送： 
主题： RE: Re: [decade] Comments on draft-song-decade-problem-statement

Yunfei,

Haibin  

Hi,

 2)Task:  

BR
Yunfei

zhangyunfei
2009-11-23

发件人：  Song  Haibin

Hi    Francois,

Good    comments.    

time    (ie    

but    

Good    point.    

this    be    

Thanks,
Haibin

---

From: Francois Le Faucheur <[email-masked]>
Date: Tue, 24 Nov 2009 11:02:04 +0100

Hello Haibin,

On 23 Nov 2009, at 04:11, Song Haibin wrote:

> it (ALTO) is the first step for peer selection,

I see. With such a meaning of "first step" then "initial" is fine.

> and after that P2P
> ALTO.

Right. But LEDBAT is relevant to the problem statement of DECADE. To put it simply, inefficiencies/bandwidth-wastage is an important part of the DECADE problem statement. And it can be argued that LEDBAT alleviates the consequences of inefficiencies/bandwidth-wastage (certainly on other applications). So I am saying the problem statement would benefit from discussing LEDBAT and clarifying that the problem is still worth solving in the presence of LEDBAT.

In other words, you want to avoid someone reading the problem statement and thinking ... well, if DECADE is all about the fact that P2P is "reaching 50-60% at the down-links and 60-90% at the uplinks" and LEDBAT is all about making sure that P2P operates fine when using up all bottleneck bandwidth while other Apps operate "almost" as if P2P load was not there, then do I really need DECADE?
So I'm suggesting that you explicitly answer that question in the problem statement.

> ALTO can reduce the backbone traffic of ISP's network by do better
> of on-evolving P2P application protocols.

However PPSP is precisely proposing to facilitate this by allowing P2P Caching using a single standard protocol (PPSP).

But that is somewhat besides the point. My point here is that we simultaneously have two problem statements (DECADE & PP2P) that propose to standardize solution for effectively storing content in-network and serving it to endusers (notably P2P clients). So I am suggesting that the DECADE problem statement should acknowledge that situation, and articulate why both flavors make sense. The input from Yunfei could also be useful for that purpose.

> DECADE will allow P2P applications

agreed.

> object to Sb and then reply to B with a message " I have started to

Yes, it could be done several ways. But the key steps will be clear anyways when you illustrate actual data transfers.

Cheers

Francois