Subject: [ppsp] 答复: QoS for PPSP

From: Ning Zong <[email-masked]>
Date: Wed, 06 Jul 2011 14:17:48 +0800

I am in favor of Yunfei’s proposal.

发件人: [email-masked] [mailto:[email-masked]] 代表
zhangyunfei
发送时间: 2011年3月31日 3:06
收件人: Schmidt, Christian 1. (NSN - DE/; ext Martin Stiemerling; ppsp@ietf.
org
主题: Re: [ppsp] QoS for PPSP

Hi Christian and all,

    My impression on the QoS related requirements is that we need propose
the requirement that how the peer and tracker protocol should do regarding
QoS issue. The solutions you proposed actually include some of such
requirements.

    So my suggestion is:

Will it be more suitable to express the requirements in the following means:

 e.g.,The peer may include QoS request info in the tracker protocol, like
the video quality and maximum delay requirements to help the tracker return
suitable peerlist.(This is just an example, not the exact requirement item).

BR

Yunfei

  _____  

zhangyunfei

2011-03-31

  _____  

发件人： Schmidt, Christian 1. (NSN - DE/Munich)

发送时间： 2011-03-30 18:08:49

收件人： ext Martin Stiemerling; zhangyunfei; [email-masked]

抄送： 

主题： QoS for PPSP

As discussed in the IETF80/PPSP I would like to start the need to include
QoS related requirements to the requirement spec.

The quality for P2P Live Streaming could be very bad. Dependent from the
number of peers in the chains between content provider and displaying peer,
the network conditions (quality and load) and the performance of the
involved entities, especially end-to-end delay could be horrible. End to end
delay of 2 minutes will be not accepted e.g. for sport games and setup or
channel switching times of 2 minutes is horrible as well. Especially if you
take into account that this service will compete with server/client based
streaming solutions.

There are several solutions possible, e.g. addition of super peers, network
internal storage and the usage of QoS information for an advanced peer
selection. This could be for example, the max length of a chunk between
source and peer or some information about the performance capacity of the
last peer. This information would have to be transported via Tracker/Peer
Protocol. The tracker protocol must provide the possibility for the request
of alternative peer addresses, if the quality is not sufficient for the
user. 

Therefore I recommend the introduction of 2 basic QoS requirements.

QoS.REQ-1: 

Setup time to receive a new streaming channel or to switch between channels
should be reasonable small. This time mainly depends on the End-to-End delay
and the size of the receiving buffer. 

QoS.REQ-2: 

End to end delay (time between content generation, e.g. camera and content
consumption, e.g. user side monitor) will become critical in case of live
streaming. Especially In provisioning of sports events, end to end delay of
1 minute and more are not acceptable. 

What do you think about?

Christian

---

From: "Schmidt, Christian 1. (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 6 Jul 2011 14:25:49 +0200

What about:

Req:

The tracker should be informed about QoS requirements (e.g. end to end delay, setup delay, media quality) and priorities of the content requesting peer.

Req:

The tracker should be informed about QoS situation (e.g. performance, available uplink bandwidth) of the content providing peer.

Best Regards

Christian

From: ext Ning Zong [mailto:[email-masked]] 
Sent: Wednesday, July 06, 2011 8:18 AM
To: 'zhangyunfei'; Schmidt, Christian 1. (NSN - DE/Munich); 'ext Martin Stiemerling'; [email-masked]
Subject: 答复: [ppsp] QoS for PPSP

发件人: [email-masked] [mailto:[email-masked]] 代表 zhangyunfei
发送时间: 2011年3月31日 3:06
收件人: Schmidt, Christian 1. (NSN - DE/; ext Martin Stiemerling; [email-masked]
主题: Re: [ppsp] QoS for PPSP

Hi Christian and all,

    My impression on the QoS related requirements is that we need propose the requirement that how the peer and tracker protocol should do regarding QoS issue. The solutions you proposed actually include some of such requirements.

    So my suggestion is:

 e.g.,The peer may include QoS request info in the tracker protocol, like the video quality and maximum delay requirements to help the tracker return suitable peerlist.(This is just an example, not the exact requirement item).

BR

Yunfei

________________________________

zhangyunfei

2011-03-31

________________________________

抄送： 

主题： QoS for PPSP

As discussed in the IETF80/PPSP I would like to start the need to include QoS related requirements to the requirement spec.

The quality for P2P Live Streaming could be very bad. Dependent from the number of peers in the chains between content provider and displaying peer, the network conditions (quality and load) and the performance of the involved entities, especially end-to-end delay could be horrible. End to end delay of 2 minutes will be not accepted e.g. for sport games and setup or channel switching times of 2 minutes is horrible as well. Especially if you take into account that this service will compete with server/client based streaming solutions.

There are several solutions possible, e.g. addition of super peers, network internal storage and the usage of QoS information for an advanced peer selection. This could be for example, the max length of a chunk between source and peer or some information about the performance capacity of the last peer. This information would have to be transported via Tracker/Peer Protocol. The tracker protocol must provide the possibility for the request of alternative peer addresses, if the quality is not sufficient for the user. 

QoS.REQ-1: 

Setup time to receive a new streaming channel or to switch between channels should be reasonable small. This time mainly depends on the End-to-End delay and the size of the receiving buffer. 

QoS.REQ-2: 

End to end delay (time between content generation, e.g. camera and content consumption, e.g. user side monitor) will become critical in case of live streaming. Especially In provisioning of sports events, end to end delay of 1 minute and more are not acceptable. 

What do you think about?

Christian

---

From: Ning Zong <[email-masked]>
Date: Thu, 07 Jul 2011 08:18:31 +0800

Hi, Christian

These look good to me. But the priority issue is mostly management related.

I will put these requirements to new revision.

Thanks.

BR,

Ning Zong

发件人: Schmidt, Christian 1. (NSN - DE/Munich)
[mailto:[email-masked]] 
发送时间: 2011年7月6日 20:26
收件人: ext Ning Zong; zhangyunfei; ext Martin Stiemerling; [email-masked]
主题: RE: [ppsp] QoS for PPSP

What about:

Req:

The tracker should be informed about QoS requirements (e.g. end to end
delay, setup delay, media quality) and priorities of the content requesting
peer.

Req:

The tracker should be informed about QoS situation (e.g. performance,
available uplink bandwidth) of the content providing peer.

Best Regards

Christian

From: ext Ning Zong [mailto:[email-masked]] 
Sent: Wednesday, July 06, 2011 8:18 AM
To: 'zhangyunfei'; Schmidt, Christian 1. (NSN - DE/Munich); 'ext Martin
Stiemerling'; [email-masked]
Subject: 答复: [ppsp] QoS for PPSP

Hi Christian and all,

    So my suggestion is:

BR

Yunfei

  _____  

zhangyunfei

2011-03-31

  _____  

抄送： 

主题： QoS for PPSP

QoS.REQ-1: 

QoS.REQ-2: 

What do you think about?

Christian

---

From: jlei <[email-masked]>
Date: Thu, 07 Jul 2011 02:33:37 +0200

In order to support QoS, the tracker may distribute peers into certain
groups according to selected criteria (e.g. media quality, available
bandwidth, existing connections). Upon receiving the request, the
tracker can easily generate peer-list according to the requirements.

However, end to end delay or setup delay, may be measured for
establishing an efficient connection between peers.
> delay, setup delay, media quality) and priorities of the content
> requesting peer.
>
> Req:
>
> *From:*ext Ning Zong [mailto:[email-masked]]
> *Sent:* Wednesday, July 06, 2011 8:18 AM
> *To:* 'zhangyunfei'; Schmidt, Christian 1. (NSN - DE/Munich); 'ext
> Martin Stiemerling'; [email-masked]
> *Subject:* 答复: [ppsp] QoS for PPSP
>
> *发件人**:[email-masked] [mailto:[email-masked]] *代
> 表***zhangyunfei
> *发送时间**:*2011年3月31日3:06
> *收件人**:*Schmidt, Christian 1. (NSN - DE/; ext Martin Stiemerling;
> [email-masked]
> *主题**:*Re: [ppsp] QoS for PPSP
>
> Hi Christian and all,
>
> the requirement that how the peer and tracker protocol should do
> regarding QoS issue. The solutions you proposed actually include some
> of such requirements.
>
> So my suggestion is:
>
> e.g.,The peer may include QoS request info in the tracker protocol,
> like the video quality and maximum delay requirements to help the
> tracker return suitable peerlist.(This is just an example, not the
> exact requirement item).
>
> BR
>
> Yunfei
>
> ------------------------------------------------------------------------
>
> zhangyunfei
>
> 2011-03-31
>
> ------------------------------------------------------------------------
>
> *发件人：*Schmidt, Christian 1. (NSN - DE/Munich)
>
> *发送时间：*2011-03-30 18:08:49
>
> *收件人：*ext Martin Stiemerling; zhangyunfei; [email-masked]
>
> *抄送：*
>
> *主题：*QoS for PPSP
>
> As discussed in the IETF80/PPSP I would like to start the need to
> include QoS related requirements to the requirement spec.
>
> The quality for P2P Live Streaming could be very bad. Dependent from
> the number of peers in the chains between content provider and
> displaying peer, the network conditions (quality and load) and the
> performance of the involved entities, especially end-to-end delay
> could be horrible. End to end delay of 2 minutes will be not accepted
> e.g. for sport games and setup or channel switching times of 2 minutes
> is horrible as well. Especially if you take into account that this
> service will compete with server/client based streaming solutions.
>
> There are several solutions possible, e.g. addition of super peers,
> network internal storage and the usage of QoS information for an
> advanced peer selection. This could be for example, the max length of
> a chunk between source and peer or some information about the
> performance capacity of the last peer. This information would have to
> be transported via Tracker/Peer Protocol. The tracker protocol must
> provide the possibility for the request of alternative peer addresses,
> if the quality is not sufficient for the user.
>
> /_QoS.REQ-1: _/
> Setup time to receive a new streaming channel or to switch between
> channels should be reasonable small. This time mainly depends on the
> End-to-End delay and the size of the receiving buffer.
>
> /_QoS.REQ-2: _/
>
> End to end delay (time between content generation, e.g. camera and
> content consumption, e.g. user side monitor) will become critical in
> case of live streaming. Especially In provisioning of sports events,
> end to end delay of 1 minute and more are not acceptable.
>
> What do you think about?
>
> Christian
>
>
> _______________________________________________
> ppsp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ppsp

---

From: "Schmidt, Christian 1. (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 7 Jul 2011 07:48:25 +0200

Hi Ning Zong,

the priority issue should cover different user requests. For example, if you want to see a popular movie, end-to-end delay is less important than quality. If you want to watch sport events, end-to-end delay is very important. The presentation should be as close to real-time as possible. Therefore the user should be able to notify his quality priority choice to the tracker.

What do you think about?

BR

Christian

From: ext Ning Zong [mailto:[email-masked]] 
Sent: Thursday, July 07, 2011 2:19 AM
To: Schmidt, Christian 1. (NSN - DE/Munich); 'zhangyunfei'; 'ext Martin Stiemerling'; [email-masked]
Subject: 答复: [ppsp] QoS for PPSP

Hi, Christian

Thanks.

BR,

Ning Zong

发件人: Schmidt, Christian 1. (NSN - DE/Munich) [mailto:[email-masked]] 
发送时间: 2011年7月6日 20:26
收件人: ext Ning Zong; zhangyunfei; ext Martin Stiemerling; [email-masked]
主题: RE: [ppsp] QoS for PPSP

What about:

Req:

Req:

Best Regards

Christian

Hi Christian and all,

    So my suggestion is:

BR

Yunfei

zhangyunfei

2011-03-31

抄送： 

主题： QoS for PPSP

QoS.REQ-1: 

QoS.REQ-2: 

What do you think about?

Christian

---

From: Ning Zong <[email-masked]>
Date: Thu, 07 Jul 2011 13:57:52 +0800

Hi, Christian,

Then the priority information can be expressed by different QoS combinations
(delay, quality), right? I think a single priority parameter (1,2,3,…)
could be difficult to be understood by trackers - or need the help from
management plane.

BR,

Ning Zong

发送时间: 2011年7月7日 13:48

Hi Ning Zong,

the priority issue should cover different user requests. For example, if you
want to see a popular movie, end-to-end delay is less important than
quality. If you want to watch sport events, end-to-end delay is very
important. The presentation should be as close to real-time as possible.
Therefore the user should be able to notify his quality priority choice to
the tracker.

What do you think about?

BR

Christian

To: Schmidt, Christian 1. (NSN - DE/Munich); 'zhangyunfei'; 'ext Martin

Hi, Christian

Thanks.

BR,

Ning Zong

What about:

Req:

Req:

Best Regards

Christian

Hi Christian and all,

    So my suggestion is:

BR

Yunfei

  _____  

zhangyunfei

2011-03-31

  _____  

抄送： 

主题： QoS for PPSP

QoS.REQ-1: 

QoS.REQ-2: 

What do you think about?

Christian

---

From: "zhangyunfei" <[email-masked]>
Date: Thu, 7 Jul 2011 14:25:43 +0800

@DEMUEXC013.nsn-intra.net> <007701cc3c6a$cf1a9ed0$6d4fdc70$@com>
Subject: =?gb2312?B?UmU6ILTwuLQ6IFtwcHNwXSBRb1MgZm9yIFBQU1A=?=
Message-ID: <[email-masked]>
X-mailer: Foxmail 6, 2, 103, 20 [cn]
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====003_Dragon018805205487_====="

This is a multi-part message in MIME format.

--=====003_Dragon018805205487_=====
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: base64

--=====003_Dragon018805205487_=====
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: base64

--=====003_Dragon018805205487_=====--