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

[Song Haibin <[e-mail]>]

Yunfei,

Thanks for your reply. I agree with your analysis here.
 
>    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.

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:[e-mail]] 
Sent: Monday, November 23, 2009 12:05 PM
To: Song Haibin; 'Francois Le Faucheur'; [e-mail]
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
	发送时间： 2009-11-23 11:19:32
	收件人： 'Francois Le Faucheur'; [e-mail]
	抄送： 
	主题： Re: [decade] Comments on draft-song-decade-problem-statement
	 
		Hi  Francois,
	 
	Good  comments.  
	   
	 
	>-----Original  Message-----
	>From:  [e-mail]  [mailto:[e-mail]]  
	>On  Behalf  Of  Francois  Le  Faucheur
	>Sent:  Friday,  November  20,  2009  10:28  PM
	>To:  [e-mail]
	>Subject:  [decade]  Comments  on
draft-song-decade-problem-statement
	>
	>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).
	 
	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.
	 
	>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].  "
	>
	 
	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.
	>"
	>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."
	>
	 
	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  
	>explicitly  discussed?
	>
	 
	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
	>[e-mail]
	>https://www.ietf.org/mailman/listinfo/decade
	>
	 
	_______________________________________________
	decade  mailing  list
	[e-mail]
	https://www.ietf.org/mailman/listinfo/decade