[ppsp] Tracker vs. No-Tracker

_______________________________________________
ppsp mailing list
ppsp@ietf.org
https://www.ietf.org/mailman/listinfo/ppsp

-- 
Dr. Jun Lei
Research Associate

Address:
Georg-August-Universitaet Goettingen
Institut fuer Informatik
Telematics Group
Lotzestrasse 16-18
37083 Goettingen 

Fax: +49 (551) 39-1 44 03
Tel: +49 (551) 39-1 35 78

Email: lei@informatik.uni-goettingen.de

_______________________________________________
ppsp mailing list
ppsp@ietf.org
https://www.ietf.org/mailman/listinfo/ppsp

-- 
Dr. Jun Lei
Research Associate

Address:
Georg-August-Universitaet Goettingen
Institut fuer Informatik
Telematics Group
Lotzestrasse 16-18
37083 Goettingen 

Fax: +49 (551) 39-1 44 03
Tel: +49 (551) 39-1 35 78

Email: lei@informatik.uni-goettingen.de

Dear all,
It can be accessed at:
Any comments are welcome!

A new version of I-D, draft-li-ppsp-nat-traversal-00.txt has been successfully
submitted by Lichun Li and posted to the IETF repository.

Filename:                
 draft-li-ppsp-nat-traversal

Revision:                
 00

Title:                

PPSP NAT traversal

Creation_date:              
   2010-10-18

WG ID:                

Independent Submission

Number_of_pages: 16

Abstract:

This document proposes a NAT traversal solution using ICE for PPSP.

To use ICE with PPSP, this document proposes some modifications to

ICE and some requirements on PPSP.  First, capable PPSP peers

function as STUN/relay servers, and PPSP protocol is used to discover

them.  Second, PPSP protocol is used to convey candidate addresses.

Third, in addition to STUN message, PPSP message is proposed as an

option to test connectivity.  Fourth, as an option, proxy peer is

proposed to relay PPSP messages.

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

 +------------+

 |relay peer E| report TURN ability

 |(TURN peer) |-------------------+          
        +------+

 +------------+                
   \                
 |peer C|

               \    
            +------+

                \    
           get |

                 \  
           peer |

         +------+report candidates     \
            list |

         |peer A|---------------->+-----+--------+<-------+

         +------+          
      |              |
 report STUN ability+-----------+

             |   tracker  
 |<--------------------|STUN peer D|

             |      
       | `            
      +-----------+

 +------+get STUN/relay peer list |          
   |

 |peer B|------------------------>+-----+--------+

 +---+--+                  
            |

      \establish            
           |

       \asociation            
         |

        \            
                  |

     +---+--------+            
        |

     |relay peer F| report proxy ability|

     |(proxy peer)|---------------------+

     +------------+

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

CDN backups
What's the mea=
ning of "ample CDN backups"?
I raised some requirements related to CDN in the WG be=
fore. I think first/hot/all chunks can be pushed to CDN nodes and CDN nodes=
 can push chunks to user nodes.
Pushin=
g first chunk can reduce the startup time.
On 10/27/2010 2:45 PM, Y=
e (Yale) Wang wrote:
> Hi,
>
> Both Pull and Push-based d=
esign have their own pros and cons.  And they
> both are used in=
 running systems: e.g., Zattoo is Push-based, PPTV is

> Pull-based, etc.
>
> Pull-based data exchange is simpler a=
nd more robust to peer churn: each
> peer just requests the data it n=
eeds and responds to requests from
> neighbors.  Neighbor substi=
tution does not impact the data exchange.

>
> However, such a design requires that each peer knows what data=
 can be
> downloaded from each neighbor.  This is usually done b=
y frequent buffer
> map exchanges between peers.
> Buffer map u=
pdate is non-negligible control overhead: e.g., if a peer

> sends buffer map update to 20 neighbors every 2 seconds, then i) the> peer need to send out 10 extra packets per second (for a 300-kbps> channel, a peer sends out ~30 packets per second on average, so the
> overhead is roughly 25%), ii) download request can be delayed 1 second=

> per hop on average (this is not good for large-scale channel).
=
>
> In push-based data exchange, uploader directly forward data to=

> downloaders.  This substantially reduces buffer map update overhe=
ad, but
> push-based design requires uploaders and downloader/subscri=
bers to
> manage their relationship (e.g., uploader decides to send w=
hich

> substreams to which downloader).  This can be very complicated> considering peer churn.
>
> Given the tradeoff, a combina=
tion of both pull and push in system design
> should not be a surpris=
e.

>
Either a hybrid design, or a design chosen for a given context:
=

- push: low churn/ample CDN backups, requiring low lags, a software tea=
m 
that can handle higher complexity

- pull: relatively higher ch=
urns, lower demand on lags, and simpler 

software design

I feel that it is a reasonable approach to first foc=
us on pull based 
systems, as I see that a real push
system will typi=
cally still need a pull based system as a backup when 
the parent//child=
 relationship

is not established or disrupted. Thus, it is a "component" of a p=
ush 
based system. I can see that
someone might argue that network co=
ding may allow pure pushed based 
systems, or the CDN is so
powerful =
that clients pull only from CDN, which can be simpler. It will 

be interesting to hear more
from designers of push based systems.
Richard

> Thanks,
> Ye
>
> On Wed, 2010-10-27 =
at 13:17 -0400, David A. Bryan wrote:
>> My take is that both are =
still in the running, despite lots of people

>> (myself, for one) leaning toward a pull-based in our proposed desi=
gn.
>> I certainly don't think this is a settled issue yet and=
 would love to
>> see some more mailing list discussion.
>&g=
t;

>> David
>>
>> On Wed, Oct 27, 2010 at 10:05 AM, Ma=
rtin Stiemerling
>> <Martin.Stiemerling@neclab.eu>  wrote:>>> Hi all,

>>>
>>> There are basically two ways on how peers &quo=
t;work out" the exchange of their data elements (i.e., the chunks):>>> - either a peer requests the download of chunks from a remote=
 peer (AKA pull-based) or

>>> - the remote peer pushes chunks to the a particular peer (AKA =
push-based). This may be either a blind-push or an informed-push.
>&g=
t;>
>>> The problem statement seems to assume a pull-based s=
ystem (Section 3, bullet 1.3) but from the mailing list and past discussion=
s it does not seem clear to me that there was a decision made.

>>>
>>> However, I see the chance to let the PPSP prot=
ocol run in both "modes", but this would require some special con=
siderations during the protocol design.
>>>
>>> So,=
 is push out of the game or didn't we consider this until yet?

>>>
>>>   Martin
>>>
>>> =
martin.st=
iemerling@neclab.eu
>>>
>>> NEC Laboratories Eu=
rope - Network Research Division

>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria =
Road, London W3 6BL | Registered in England 2832014
>>>
>=
>>
>>> _______________________________________________
>>> ppsp mailing list
>>> ppsp@ietf.org
>>> https://www.ietf.org=
/mailman/listinfo/ppsp

_______________________________________________
ppsp mailing list
ppsp@ietf.org
https://=
www.ietf.org/mailman/listinfo/ppsp

----------------------------------=
----------------------
ZTE Information Security Notice: The information&n=
bsp;contained in this mail is solely property=
 of the sender's organization. This mail&=
nbsp;communication is confidential. Recipients named&nb=
sp;above are obligated to maintain secrecy an=
d are not permitted to disclose the cont=
ents of this communication to others.
This email and any files transmitted with&nbs=
p;it are confidential and intended solely for=
 the use of the individual or entity&nbs=
p;to whom they are addressed. If you hav=
e received this email in error please no=
tify the originator of the message. Any =
views expressed in this message are those&nbs=
p;of the individual sender.
This message has been scanned for viruses&nbs=
p;and Spam by ZTE Anti-Spam system.

What's the meaning of =
"ample CDN
backups"?
I raised some requirements =
related to
CDN in the WG before. I think first/hot/all chunks can be pushed to CDN =
nodes
and CDN nodes can push chunks to user nodes.
Pushing first chunk can =
reduce the
startup time.
On 10/27/2010 2:45 PM, Ye =
(Yale) Wang
wrote:
> Hi,
>
> Both Pull and Push-based design have their own pros and cons.
 And they
> both are used in running systems: e.g., Zattoo is Push-based, =
PPTV is
> Pull-based, etc.
>
> Pull-based data exchange is simpler and more robust to peer =
churn:
each
> peer just requests the data it needs and responds to requests =
from
> neighbors.  Neighbor substitution does not impact the data
exchange.
>
> However, such a design requires that each peer knows what data =
can be
> downloaded from each neighbor.  This is usually done by =
frequent
buffer
> map exchanges between peers.
> Buffer map update is non-negligible control overhead: e.g., if =
a peer
> sends buffer map update to 20 neighbors every 2 seconds, then =
i) the
> peer need to send out 10 extra packets per second (for a =
300-kbps
> channel, a peer sends out ~30 packets per second on average, so =
the
> overhead is roughly 25%), ii) download request can be delayed 1 =
second
> per hop on average (this is not good for large-scale =
channel).
>
> In push-based data exchange, uploader directly forward data =
to
> downloaders.  This substantially reduces buffer map update
overhead, but
> push-based design requires uploaders and downloader/subscribers =
to
> manage their relationship (e.g., uploader decides to send =
which
> substreams to which downloader).  This can be very =
complicated
> considering peer churn.
>
> Given the tradeoff, a combination of both pull and push in =
system
design
> should not be a surprise.
>
Either a hybrid design, or a design chosen for a given =
context:
- push: low churn/ample CDN backups, requiring low lags, a software =
team 
that can handle higher complexity
- pull: relatively higher churns, lower demand on lags, and simpler =

software design
I feel that it is a reasonable approach to first focus on pull based =

systems, as I see that a real push
system will typically still need a pull based system as a backup =
when 
the parent//child relationship
is not established or disrupted. Thus, it is a "component" =
of a
push 
based system. I can see that
someone might argue that network coding may allow pure pushed based =

systems, or the CDN is so
powerful that clients pull only from CDN, which can be simpler. It =
will 
be interesting to hear more
from designers of push based systems.
Richard
> Thanks,
> Ye
>
> On Wed, 2010-10-27 at 13:17 -0400, David A. Bryan =
wrote:
>> My take is that both are still in the running, despite lots =
of
people
>> (myself, for one) leaning toward a pull-based in our =
proposed
design.
>> I certainly don't think this is a settled issue yet and =
would love
to
>> see some more mailing list discussion.
>>
>> David
>>
>> On Wed, Oct 27, 2010 at 10:05 AM, Martin =
Stiemerling
>> <Martin.Stiemerling@neclab.eu>  wrote:
>>> Hi all,
>>>
>>> There are basically two ways on how peers "work =
out"
the exchange of their data elements (i.e., the chunks):
>>> - either a peer requests the download of chunks from a =
remote
peer (AKA pull-based) or
>>> - the remote peer pushes chunks to the a particular =
peer (AKA
push-based). This may be either a blind-push or an =
informed-push.
>>>
>>> The problem statement seems to assume a pull-based =
system
(Section 3, bullet 1.3) but from the mailing list and past discussions =
it does
not seem clear to me that there was a decision made.
>>>
>>> However, I see the chance to let the PPSP protocol run =
in both
"modes", but this would require some special considerations =
during
the protocol design.
>>>
>>> So, is push out of the game or didn't we consider this =
until yet?
>>>
>>>   Martin
>>>
>>> martin.stiemerling@neclab.eu
>>>
>>> NEC Laboratories Europe - Network Research =
Division
>>> NEC Europe Limited | Registered Office: NEC House, 1 =
Victoria
Road, London W3 6BL | Registered in England 2832014
>>>
>>>
>>> =
_______________________________________________
>>> ppsp mailing list
>>> ppsp@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ppsp
_______________________________________________
ppsp mailing list
ppsp@ietf.org
https://www.ietf.org/mailman/listinfo/ppsp
--------------------------------------------------------<=
/pre>ZTE Information Security Notice: The i=
nformation contained in this mail is solely=
 property of the sender's organization. Thi=
s mail communication is confidential. Recipients=
 named above are obligated to maintain =
;secrecy and are not permitted to disclose&=
nbsp;the contents of this communication to =
others.
This email and any files=
 transmitted with it are confidential and&n=
bsp;intended solely for the use of the =
;individual or entity to whom they are =
;addressed. If you have received this email=
 in error please notify the originator =
;of the message. Any views expressed in&nbs=
p;this message are those of the individual&=
nbsp;sender.
This message has been&nb=
sp;scanned for viruses and Spam by ZTE =
;Anti-Spam system.
What's the meaning of =
"ample CDN
backups"?
I raised some requirements =
related to
CDN in the WG before. I think first/hot/all chunks can be pushed to CDN =
nodes
and CDN nodes can push chunks to user nodes.
Pushing first chunk can =
reduce the
startup time.
On 10/27/2010 2:45 PM, Ye =
(Yale) Wang
wrote:
> Hi,
>
> Both Pull and =
Push-based design
have their own pros and cons.  And they
> both are used in =
running
systems: e.g., Zattoo is Push-based, PPTV is
> Pull-based, =
etc.
>
> Pull-based data =
exchange is
simpler and more robust to peer churn: each
> peer just requests the =
data it
needs and responds to requests from
> neighbors. =
 Neighbor
substitution does not impact the data exchange.
>
> However, such a design =
requires
that each peer knows what data can be
> downloaded from each =
neighbor.
 This is usually done by frequent buffer
> map exchanges between =
peers.
> Buffer map update is =
non-negligible
control overhead: e.g., if a peer
> sends buffer map update =
to 20
neighbors every 2 seconds, then i) the
> peer need to send out =
10 extra
packets per second (for a 300-kbps
> channel, a peer sends =
out ~30
packets per second on average, so the
> overhead is roughly =
25%), ii)
download request can be delayed 1 second
> per hop on average =
(this is not
good for large-scale channel).
>
> In push-based data =
exchange,
uploader directly forward data to
> downloaders.  This
substantially reduces buffer map update overhead, but
> push-based design =
requires
uploaders and downloader/subscribers to
> manage their =
relationship (e.g.,
uploader decides to send which
> substreams to which =
downloader).
 This can be very complicated
> considering peer =
churn.
>
> Given the tradeoff, a
combination of both pull and push in system design
> should not be a =
surprise.
>
Either a hybrid design, or a =
design
chosen for a given context:
- push: low churn/ample CDN =
backups,
requiring low lags, a software team 
that can handle higher =
complexity
- pull: relatively higher =
churns,
lower demand on lags, and simpler 
software =
design
I feel that it is a =
reasonable
approach to first focus on pull based 
systems, as I see that a =
real push
system will typically still =
need a
pull based system as a backup when 
the parent//child =
relationship
is not established or =
disrupted.
Thus, it is a "component" of a push 
based system. I can see =
that
someone might argue that =
network
coding may allow pure pushed based 
systems, or the CDN is =
so
powerful that clients pull =
only from
CDN, which can be simpler. It will 
be interesting to hear =
more
from designers of push based =
systems.
Richard
> =
Thanks,
> Ye
>
> On Wed, 2010-10-27 at =
13:17
-0400, David A. Bryan wrote:
>> My take is that =
both are
still in the running, despite lots of people
>> (myself, for one) =
leaning
toward a pull-based in our proposed design.
>> I certainly don't =
think this
is a settled issue yet and would love to
>> see some more =
mailing list
discussion.
>>
>> =
David
>>
>> On Wed, Oct 27, =
2010 at
10:05 AM, Martin Stiemerling
>>
<Martin.Stiemerling@neclab.eu>  wrote:
>>> Hi =
all,
>>>
>>> There are =
basically two
ways on how peers "work out" the exchange of their data =
elements
(i.e., the chunks):
>>> - either a peer =
requests
the download of chunks from a remote peer (AKA pull-based) =
or
>>> - the remote =
peer pushes
chunks to the a particular peer (AKA push-based). This may be either a
blind-push or an informed-push.
>>>
>>> The problem =
statement
seems to assume a pull-based system (Section 3, bullet 1.3) but from the
mailing list and past discussions it does not seem clear to me that =
there was a
decision made.
>>>
>>> However, I see =
the
chance to let the PPSP protocol run in both "modes", but this =
would
require some special considerations during the protocol =
design.
>>>
>>> So, is push out =
of the
game or didn't we consider this until yet?
>>>
>>>   =
Martin
>>>
>>>
martin.stiemerling@neclab.eu
>>>
>>> NEC =
Laboratories Europe
- Network Research Division
>>> NEC Europe =
Limited |
Registered Office: NEC House, 1 Victoria Road, London W3 6BL | =
Registered in
England 2832014
>>>
>>>
>>>
_______________________________________________
>>> ppsp mailing =
list
>>> =
ppsp@ietf.org
>>>
https://www.ietf.org/mailman/listinfo/ppsp
______________________________________________=
_
ppsp mailing =
list
ppsp@ietf.org
https://www.ietf.org/mailman/listinfo/ppsp
--------------------------------------------------------<=
/pre>ZTE Information Security Notice: The i=
nformation contained in this mail is solely=
 property of the sender's organization. Thi=
s mail communication is confidential. Recipients=
 named above are obligated to maintain =
;secrecy and are not permitted to disclose&=
nbsp;the contents of this communication to =
others.
This email and any files=
 transmitted with it are confidential and&n=
bsp;intended solely for the use of the =
;individual or entity to whom they are =
;addressed. If you have received this email=
 in error please notify the originator =
;of the message. Any views expressed in&nbs=
p;this message are those of the individual&=
nbsp;sender.
This message has been&nb=
sp;scanned for viruses and Spam by ZTE =
;Anti-Spam system.
What's the meaning of=
 "ample=20
CDN backups"?
I raised some requirements re=
lated=20
to CDN in the WG before. I think first/hot/all chunks can be pushed to CDN =
nodes=20
and CDN nodes can push chunks to user nodes.
Pushing first chunk can reduc=
e the=20
startup time.
On 10/27/2010 2:45 PM, Ye (Yale) Wang=20
wrote:
>
> Both Pull and Push-based design have =
their=20
own pros and cons.  And they
> both are used in running=
=20
systems: e.g., Zattoo is Push-based, PPTV is
> Pull-based,=
=20
etc.
>
> Pull-based data exchange is simpler =
and=20
more robust to peer churn: each
> peer just requests the dat=
a it=20
needs and responds to requests from
> neighbors.  Neigh=
bor=20
substitution does not impact the data=20
exchange.
>
> However, such a design requires=
 that=20
each peer knows what data can be
> downloaded from each neig=
hbor.=20
 This is usually done by frequent buffer
> map exchange=
s=20
between peers.
> Buffer map update is non-negligible control=
=20
overhead: e.g., if a peer
> sends buffer map update to 20=20
neighbors every 2 seconds, then i) the
> peer need to send o=
ut 10=20
extra packets per second (for a 300-kbps
> channel, a peer s=
ends=20
out ~30 packets per second on average, so the
> overhead is=
=20
roughly 25%), ii) download request can be delayed 1 second
>=
 per=20
hop on average (this is not good for large-scale=20
channel).
>
> In push-based data exchange,=20
uploader directly forward data to
> downloaders.  This=
=20
substantially reduces buffer map update overhead, but
>=20
push-based design requires uploaders and downloader/subscribers=20
to
> manage their relationship (e.g., uploader decides to se=
nd=20
which
> substreams to which downloader).  This can be v=
ery=20
complicated
> considering peer=20
churn.
>
> Given the tradeoff, a combination =
of=20
both pull and push in system design
> should not be a=20
surprise.
>
Either a hybrid design, or a design=
=20
chosen for a given context:
- push: low churn/ample CDN bac=
kups,=20
requiring low lags, a software team 
that can handle higher=20
complexity
- pull: relatively higher churns, lower demand o=
n=20
lags, and simpler 
software design
I feel that =
it is=20
a reasonable approach to first focus on pull based 
systems, as=
 I=20
see that a real push
system will typically still need a pull ba=
sed=20
system as a backup when 
the parent//child=20
relationship
is not established or disrupted. Thus, it is a=20
"component" of a push 
based system. I can see=20
that
someone might argue that network coding may allow pure pus=
hed=20
based 
systems, or the CDN is so
powerful that clie=
nts=20
pull only from CDN, which can be simpler. It will 
be interesti=
ng to=20
hear more
from designers of push based=20
systems.
Richard
> Thanks,
&=
gt;=20
Ye
>
> On Wed, 2010-10-27 at 13:17 -0400, Dav=
id A.=20
Bryan wrote:
>> My take is that both are still in the run=
ning,=20
despite lots of people
>> (myself, for one) leaning towar=
d a=20
pull-based in our proposed design.
>> I certainly don'=
;t think=20
this is a settled issue yet and would love to
>> see some=
 more=20
mailing list discussion.
>>
>>=20
David
>>
>> On Wed, Oct 27, 2010 at 10:=
05=20
AM, Martin Stiemerling
>> <Martin.Stiemerling@neclab.eu>=
=20
 wrote:
>>> Hi=20
all,
>>>
>>> There are basically =
two=20
ways on how peers "work out" the exchange of their data elements =
(i.e., the=20
chunks):
>>> - either a peer requests the download of=
=20
chunks from a remote peer (AKA pull-based) or
>>> - th=
e=20
remote peer pushes chunks to the a particular peer (AKA push-based). This m=
ay be=20
either a blind-push or an=20
informed-push.
>>>
>>> The proble=
m=20
statement seems to assume a pull-based system (Section 3, bullet 1.3) but f=
rom=20
the mailing list and past discussions it does not seem clear to me that the=
re=20
was a decision made.
>>>
>>> Howe=
ver,=20
I see the chance to let the PPSP protocol run in both "modes", bu=
t this would=20
require some special considerations during the protocol=20
design.
>>>
>>> So, is push out o=
f the=20
game or didn't we consider this until=20
yet?
>>>
>>>  =20
Martin
>>>
>>>=20
martin.st=
iemerling@neclab.eu
>>>
>>>=
=20
NEC Laboratories Europe - Network Research Division
>>>=
; NEC=20
Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6=
BL |=20
Registered in England=20
2832014
>>>
>>>
>&=
gt;>=20
_______________________________________________
>>> pp=
sp=20
mailing list
>>> ppsp@ietf.org
>>>=20
ht=
tps://www.ietf.org/mailman/listinfo/ppsp
__________________=
_____________________________
ppsp=20
mailing=20
list
ppsp@ie=
tf.org
https://www.ietf.org/mailman/listinfo/ppsp
-----------------=
---------------------------------------
ZTE Information =
;Security Notice: The information contained in&nbs=
p;this mail is solely property of the se=
nder's organization. This mail communication i=
s confidential. Recipients named above are ob=
ligated to maintain secrecy and are not =
permitted to disclose the contents of this&nb=
sp;communication to others.
This email and any files transmitted wit=
h it are confidential and intended solely&nbs=
p;for the use of the individual or entit=
y to whom they are addressed. If you&nbs=
p;have received this email in error please&nb=
sp;notify the originator of the message. Any&=
nbsp;views expressed in this message are thos=
e of the individual sender.
This message has been scanned for viruse=
s and Spam by ZTE Anti-Spam system.