Subject: [ppsp] comments on latency in tracker protocol

From: Xiajinwei <[email-masked]>
Date: Thu, 08 Mar 2012 08:32:15 +0000

Hi all,

Let's push this work forward.

According to the discussion in the conference call, IMHO this 07 version has significant enhancement on quality, and its structure is much clearer compared to last version. For the latency concern raised in the call, I think latency indeed is an important element which impacts the user experience. Actually, user usually can't tolerate much latency during multimedia playback, but be a little patient on the beginning of multimedia playback. The beginning latency is mainly induced by a set of components, such as multicast joining, data transferring, buffering, decoding and demultiplexing. The Information acquisition latency (the time it takes peer to acquire the information from tracker) should be also in the scope of beginning latency. Let's consider VoIP use case, SIP procedure is also necessary before the VoIP data transferring.

Hope this explanation is useful.

Thank you

Jinwei

---

From: zhangyunfei <[email-masked]>
Date: Fri, 9 Mar 2012 15:41:32 +0800

I reviewed the draft and raised the comments in the call. I would say basically I agree with Jianwei's opinion on the general impression of the draft .
Regarding the proposal of merging the messages, like CONNECT and JOIN, several factors should be considered first:
1)Are these necessarily independent actions or can merged into one action from the users' perspective? Obviously peers can CONNECT a system without JOIN action, i.e., Tom opened the PPLive software without clicking on ANY programs.
2) The effect of the merger:  As a standard protocol, we need to balance between performance and compatibility with existing protocols. We are not facing a new problem even without proprietary solutions. Instead we are facing a problem with many existing solutions. We need to consider how to make it compatible with them while at the same time keeping it efficient enough. We cannot focus on one side at the risk of neglecting the one. I think this is the baseline principle in the PPSP protocol design.
   So back to the latency problem, of course we need to consider the efficiency issue. Convincing figures from references may be helpful to make people better understand the value of the merger or vice versa.

BR
Yunfei

zhangyunfei

From: Xiajinwei
Date: 2012-03-08 16:32
To: [email-masked]
Subject: [ppsp] comments on latency in tracker protocol
Hi all,
 
Let’s push this work forward.
 
According to the discussion in the conference call, IMHO this 07 version has significant enhancement on quality, and its structure is much clearer compared to last version. For the latency concern raised in the call, I think latency indeed is an important element which impacts the user experience. Actually, user usually can’t tolerate much latency during multimedia playback, but be a little patient on the beginning of multimedia playback. The beginning latency is mainly induced by a set of components, such as multicast joining, data transferring, buffering, decoding and demultiplexing. The Information acquisition latency (the time it takes peer to acquire the information from tracker) should be also in the scope of beginning latency. Let’s consider VoIP use case, SIP procedure is also necessary before the VoIP data transferring.

Thank you
 
Jinwei

---

From: Arno Bakker <[email-masked]>
Date: Fri, 9 Mar 2012 15:49:07 +0100

On 08/03/2012 09:32, Xiajinwei wrote:
> The Information acquisition latency (the
> time it takes peer to acquire the information from tracker) should be
> also in the scope of beginning latency. Let’s consider VoIP use case,
> SIP procedure is also necessary before the VoIP data transferring.
>

Hi

my objection is with the time it takes to obtain a list of peers from 
the tracker. Currently this requires the following interaction:

HTTPS handshake
CONNECT
OK
JOIN swarm
OK + peers

So the CONNECT adds an extra roundtrip delay to the process. I'd rather
have some multiplexing:

HTTPS handshake
CONNECT+JOIN
OK + peer

As remarked by Yunfei, you may also want to leave open the option of not 
using HTTPS in benign environments, the HTTPS handshake is also 
expensive (2 round trips + crypto).

I will post a more complete review later.

CU,
     Arno

---

From: Riccardo Bernardini <[email-masked]>
Date: Fri, 09 Mar 2012 18:28:14 +0100

zhangyunfei <[email-masked]> ha scritto:

> I reviewed the draft and raised the comments in the call. I would  
> say basically I agree with Jianwei's opinion on the general  
> impression of the draft .
> Regarding the proposal of merging the messages, like CONNECT and  
> JOIN, several factors should be considered first:
> 1)Are these necessarily independent actions or can merged into one  
> action from the users' perspective? Obviously peers can CONNECT a  
> system without JOIN action, i.e., Tom opened the PPLive software  
> without clicking on ANY programs.
> 2) The effect of the merger:  As a standard protocol, we need to  
> balance between performance and compatibility with existing  
> protocols. We are not facing a new problem even without proprietary  
> solutions. Instead we are facing a problem with many existing  
> solutions. We need to consider how to make it compatible with them  
> while at the same time keeping it efficient enough. We cannot focus  
> on one side at the risk of neglecting the one. I think this is the  
> baseline principle in the PPSP protocol design.
>    So back to the latency problem, of course we need to consider the  
> efficiency issue. Convincing figures from references may be helpful  
> to make people better understand the value of the merger or vice  
> versa.
>

Just a few considerations about the latency issue.  First, do we have  
some measurement about the actual delays? (Maybe it is what you call  
"convincing figures"?)   Should I guess, I expect that the overall  
"connection setup + CONNECT + JOIN" will take an amount of time  
comparable to the time needed to access a web page via HTTPS with some  
images included (CONNECT would be the equivalent of the first GET and  
JOIN the equivalent of a GET done to get an image).  However, this is  
just a guess of mine and having some figure it could be easier to  
decide if JOIN and CONNECT need to be merged.

 From another point of view, I like the flexibility of having them  
separated.  As said above, maybe in some application one would like to  
do a CONNECT without JOIN.   Also, is it possible that one JOINs more  
than one swarm at time? For example, if I want to implement something  
similar to the "exchange" button found on many remotes (that brings  
you back to the previous channel), it could make sense to remain  
JOINed to a swarm even when I "change channel."  If the "multiple  
JOIN" scenario is reasonable, we should have at least a "CONNECT+JOIN"  
and a "simple JOIN".

Let me throw in a proposal. Maybe a possible solution could be having  
more than one command in the same message.  This could be achieved  
with just a little change of the proposed XML syntax: just make the  
command name an attribute of Request and let Request include all the  
request parameters.  For example, instead of

<PPSPTrackerProtocol version="1.0">
    <Request>CONNECT</Request>
    <PeerID>6543210</PeerID>
    <TransactionID>12345</TransactionID>
    ....
</PPSPTrackerProtocol>

use

<PPSPTrackerProtocol version="1.0">
    <Request action="CONNECT">
      <PeerID>6543210</PeerID>
      <TransactionID>12345</TransactionID>
      ....
    </Request>
</PPSPTrackerProtocol>

A similar change would apply also to the "Response" node.  In this way  
one can include more than one request in the same transaction and the  
server will process them in order, as they were received in separate  
transactions.   This will save one round-trip request-response time.   
The only possible drawback could be that with this change we lose  
compatibility with some other protocol (that I am not aware of).

Riccardo

> Let?s push this work forward.
>
> According to the discussion in the conference call, IMHO this 07  
> version has significant enhancement on quality, and its structure is  
> much clearer compared to last version. For the latency concern  
> raised in the call, I think latency indeed is an important element  
> which impacts the user experience. Actually, user usually can?t  
> tolerate much latency during multimedia playback, but be a little  
> patient on the beginning of multimedia playback. The beginning  
> latency is mainly induced by a set of components, such as multicast  
> joining, data transferring, buffering, decoding and demultiplexing.  
> The Information acquisition latency (the time it takes peer to  
> acquire the information from tracker) should be also in the scope of  
> beginning latency. Let?s consider VoIP use case, SIP procedure is  
> also necessary before the VoIP data transferring.
>

-- 
Riccardo Bernardini
DIEGM -- University of Udine
via delle Scienze 208
33100 Udine
Tel: +39-0432-55-8271
Fax: +39-0432-55-8251

----------------------------------------------------------------------
SEMEL (SErvizio di Messaging ELettronico) - AINF, Universita' di Udine

---

From: Rui Cruz <[email-masked]>
Date: Fri, 9 Mar 2012 17:41:54 +0000

Hi,

Arno is right, as well as Jinwei and Yunfei in all viewpoints.

And we have a pretty solution for it.
It was not considered to be included in the revised draft, although discussed, as its applicability needs to be very carefully addressed.

Considering the following very common scenarios:

a: User signs in to the Provider portal through his WebTV interface (a STB or a Tablet or a PC), browses the available "shows" and selects one to watch. Later, pauses and selects another show (while the first one can be kept being shared in that swarm, although not being displayed, or being displayed as a PIP window).

b: User has been watching several shows but has to leave and power off the device. But user wants to return and then resume all he was engaged in, and continue watching the show he paused, even from the same moment in the show timeline.

For scenario a and b, in a first time, the Peer would just CONNECT to the system while the User browses until deciding what to JOIN. Subsequent JOINs (scenario a, later actions) get the Peer in different swarms that the User can manage (DISCONNECT or re-JOIN).

For scenario b, when resuming, the Peer CONNECTs but with specific JOIN actions included in the same Request message.
This involves a slight change in the CONNECT message semantics only, and so, IMHO, addresses the latency concern in a very elegant way. Independently of using more or less secure handshake methods. However, the use of this special method should be carefully considered, not just in terms of security.

An example of the modified CONNECT message is the following, where the Peer selects the desired swarms and specifies the corresponding PeerMode (SEED or LEECH).
The optional element in the CONNECT message is the SwarmID and respective attributes, as well as the conditionally mandatory (depending on the presence of element SwarmID) element PeerNum:

<PPSPTrackerProtocol version="1.0">
    <Request>CONNECT</Request>
    <PeerID>656164657221</PeerID>
    <!-- in CONNECT, SwarmID element can take optional @action to JOIN a swarm. Additionally inform about the corresponding @peerMode. -->
    <SwarmID action="JOIN" peerMode="SEED">1111</SwarmID>
    <SwarmID action="JOIN" peerMode="LEECH">2222</SwarmID>
    <!-- in CONNECT, with optional JOIN @action, @abilityNAT values "STUN"|"TURN"|"PROXY" -->
    <PeerNum abilityNAT="STUN">5</PeerNum>
    <TransactionID>12345</TransactionID>
    <PeerGroup>
        <PeerInfo>
            <PeerID>656164657221</PeerID>
            <PeerMode>SEED</PeerMode>
            <!-- @addrType values "ipv4|ipv6", @type values "HOST"|"REFLEXIVE"|"PROXY" -->
            <PeerAddress addrType="ipv4" ip="198.51.100.1" port="80" priority="1" type="HOST"
                connection="ADSL" asn="64496"/>
            <PeerAddress addrType="ipv6" ip="2001:db8::1" port="80" priority="2" type="HOST"
                connection="3G" asn="65536"/>
        </PeerInfo>
    </PeerGroup>
</PPSPTrackerProtocol>

Comparing with the previous CONNECT message:

<PPSPTrackerProtocol version="1.0">
    <Request>CONNECT</Request>
    <PeerID>656164657221</PeerID>
    <TransactionID>12345</TransactionID>
    <PeerGroup>
        <PeerInfo>
            <PeerID>656164657221</PeerID>
            <PeerMode>SEED</PeerMode>
            <!-- @addrType values "ipv4|ipv6", @type values "HOST"|"REFLEXIVE"|"PROXY" -->
            <PeerAddress addrType="ipv4" ip="198.51.100.1" port="80" priority="1" type="HOST"
                connection="ADSL" asn="64496"/>
            <PeerAddress addrType="ipv6" ip="2001:db8::1" port="80" priority="2" type="HOST"
                connection="3G" asn="65536"/>
        </PeerInfo>
    </PeerGroup>
</PPSPTrackerProtocol>

Regards,

Rui Cruz
[email-masked]

IST/INESC-ID/INOV - Lisbon, Portugal
__________________________________________
ppsp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ppsp

On 09/03/2012, at 14:49, Arno Bakker wrote:

> my objection is with the time it takes to obtain a list of peers from the tracker. Currently this requires the following interaction:
> 
> HTTPS handshake
> CONNECT
> OK
> JOIN swarm
> OK + peers
> 
> As remarked by Yunfei, you may also want to leave open the option of not using HTTPS in benign environments, the HTTPS handshake is also expensive (2 round trips + crypto).
> 
> _______________________________________________
> ppsp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ppsp

---

From: Rui Cruz <[email-masked]>
Date: Fri, 9 Mar 2012 17:51:13 +0000

[CORRECTION: there was a wrong PeerMode line in the PeerInfo group of previous example]

Hi,

Regards,

Rui Cruz
[email-masked]

---

From: Rui Cruz <[email-masked]>
Date: Fri, 9 Mar 2012 19:13:48 +0000

The message sequence for the example I illustrated would be:

CONNECT with implicit JOINs:

   +--------+      +--------+     +--------+    +---------+  +--------+
   | Player |      | Peer 1 |     | Portal |    | Tracker |  | Peer 2 |
   +--------+      +--------+     +--------+    +---------+  +--------+
      |                |               |              |           |
      |--Page request----------------->|              |           |
      |<--------------Page with links--|              |           |
      |--Select stream (MPD Request)-->|              |           |
      |<-----------------------OK+MPD--|              |           |
      |--MPD---------->|--CONNECT (join x, y)-------->|           |
      |<-----------OK--|<----------OK+Peerlist(x, y)--|           |
      |                |                              |           |
      |-- Get(Chunk) ->|<---------- (Peer protocol) ------------->|
      |<---- Chunk ----|<-------------------------------- Chunk --|
      :                :               :              :           :

Regards,

Rui Cruz
[email-masked]

---

From: Rui Cruz <[email-masked]>
Date: Fri, 9 Mar 2012 19:17:29 +0000

[CORRECTION: just the resuming action is valid in this case]

      |--Resume------->|--CONNECT (join x, y)-------->|           |

Regards,

Rui Cruz
[email-masked]

---

From: Arno Bakker <[email-masked]>
Date: Mon, 12 Mar 2012 08:52:03 +0100

Rui Cruz wrote:
> the Peer CONNECTs but with specific JOIN
> actions included in the same Request message.

Hi

This multiplexing of instructions is indeed what we need to reduce latency.

CU,
     Arno

---

From: zhangyunfei <[email-masked]>
Date: Mon, 12 Mar 2012 17:22:01 +0800

I think this is a feasible way to address the problem. I don't see incompatibility with some other protocols till now.

BR
Yunfei 

zhangyunfei

From: Riccardo Bernardini
Date: 2012-03-10 01:28
To: ppsp
Subject: Re: [ppsp] comments on latency in tracker protocol

use

Riccardo

---

From: zhangyunfei <[email-masked]>
Date: Mon, 12 Mar 2012 17:25:46 +0800

I think this proposal is in line with Riccardo's proposal. So both seem okay.

BR
Yunfei

zhangyunfei

From: Rui Cruz
Date: 2012-03-10 01:51
To: ppsp
CC: Rui Cruz; [email-masked] ([email-masked]); zhangyunfei ([email-masked]); Xiajinwei; "M醨io Serafim Nunes, Eng."
Subject: Re: [ppsp] comments on latency in tracker protocol - corrected
[CORRECTION: there was a wrong PeerMode line in the PeerInfo group of previous example]

Hi,

Regards,

Rui Cruz
[email-masked]

Hi

HTTPS handshake
CONNECT
OK
JOIN swarm
OK + peers

HTTPS handshake
CONNECT+JOIN
OK + peer

CU,
   Arno

---

From: Rui Cruz <[email-masked]>
Date: Mon, 12 Mar 2012 09:26:26 +0000

Hi Riccardo,

Read inline...

Regards,

Rui Cruz
[email-masked]

On 09/03/2012, at 17:28, Riccardo Bernardini wrote:
> 
> From another point of view, I like the flexibility of having them separated.  As said above, maybe in some application one would like to do a CONNECT without JOIN.   Also, is it possible that one JOINs more than one swarm at time? For example, if I want to implement something similar to the "exchange" button found on many remotes (that brings you back to the previous channel), it could make sense to remain JOINed to a swarm even when I "change channel."  If the "multiple JOIN" scenario is reasonable, we should have at least a "CONNECT+JOIN" and a "simple JOIN".

That kind of scenario of a "resume"-like feature can be perfectly addressed with the simple solution I have presented.