Subject: Re: [ppsp] Draft-ietf-ppsp-req-01

From: "Schmidt, Christian 1. (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 7 Mar 2011 11:05:53 +0100

Hi Ning Zong,

I do not agree, that basic QoS issues should not be a normative requirement for PPSP system. I think they are essential to this services.

what about the proposal to include a section Quality of Service 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 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 seems to be not acceptable.”

QoS.REQ-3: 

“The user should receive an error free copy of the original streaming. This can be done with addition of redundancy and the usage of packet retransmission. But the additional delay has to be taken into account.”

What do you think about?

BR

Christian

 

From: ext Ning Zong [mailto:[email-masked]] 
Sent: Friday, February 25, 2011 1:28 AM
To: Schmidt, Christian 1. (NSN - DE/Munich); 'ext zhangyunfei'; [email-masked]
Subject: 答复: [ppsp] Draft-ietf-ppsp-req-01

Hi, Schmidt,

Your suggestion is good, although I think this new text could be in explanatory text rather than in the formal requirement body.

BTW, I have post a new revision -02 and forward the message to the list, but it seems that it doesn’t come out. So I attached the link to the new version as below

http://tools.ietf.org/html/draft-ietf-ppsp-reqs-02

The main differences between -02 and -01 can be found in:

http://tools.ietf.org/rfcdiff?url2=draft-ietf-ppsp-reqs-02.txt

BR,

Ning Zong

发件人: [email-masked] [mailto:[email-masked]] 代表 Schmidt, Christian 1. (NSN - DE/Munich)
发送时间: 2011年2月24日 20:56
收件人: ext zhangyunfei; [email-masked]
主题: [ppsp] Draft-ietf-ppsp-req-01

Hi Yunfei,

a proposal related to PPSP.REQ-7:

   “PPSP.REQ-7: The Tracker Protocol and Peer Protocol SHOULD enable

   peers to receive streaming data within the time constraints required

   by specific content items.”

CS: We should be a little bit more specific here. I think, that delay will

be the most critical QoS issues, especially for p2p live streaming.

We should add:

Proposal:

   “PPSP.REQ-7: The Tracker Protocol and Peer Protocol SHOULD enable

   peers to receive streaming data within the time constraints required

   by specific content items. End to end delay will become critical in case

   of live streaming. Especially In provisioning of sports events, 

  end to end delay of 1 minute and more seems to be not acceptable.”

What do you think about?

Best Regards

Christian

---

From: "Schmidt, Christian 1. (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 7 Mar 2011 11:34:51 +0100

Hi Yunfei,

an additional proposal for the peer protocol security issues.

Current text:

   Similar to the behaviour in the tracker-peer interaction, malicious

   peers may also create fake information on chunk availability and

   exchange it with other peers. Some techniques to check the data

   integrity (e.g., using checksum) may be useful for detecting the
data.

   But this part is out of scope of PPSP.

Proposed new text:   

   Similar to the behaviour in the tracker-peer interaction, malicious

   peers may also create fake information on chunk availability and

   exchange it with other peers. 

   Malicious peers can also modify stream contents. Some techniques 

   are available and useful to check the data integrity (e.g., using
checksum).

   The related information can be received from the tracker via the
tracker protocol.

   The selection of a certain mechanism for this purpose is out of scope
for PPSP.

What do you think about this?

BR

Christian

---

From: "zhangyunfei" <[email-masked]>
Date: Mon, 7 Mar 2011 19:37:36 +0800

[email-masked]>
Subject: Re: Review: draft-ietf-pp2p-problem-statement-01 / Security
Message-ID: <[email-masked]>
X-mailer: Foxmail 6, 2, 103, 20 [cn]
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====003_Dragon457686747206_====="

This is a multi-part message in MIME format.

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

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

--=====003_Dragon457686747206_=====--

---

From: Ning Zong <[email-masked]>
Date: Tue, 08 Mar 2011 09:39:51 +0800

Hi, Schmidt,

I agree that these requirements of QoS are important to P2P streaming
system. However, I still don’t see how these QoS requirements impact the
design of Tracker & Peer Protocol, bearing in mind that our scope is not
developing a P2P streaming system. Instead, IMO, these requirements could be
addressed by some video transmission protocols such as those developed in
AVT WG.

Could you give some examples on how these QoS issue will apply to Tracker &
Peer Protocol?

Thanks.

BR,

Ning Zong

发件人: Schmidt, Christian 1. (NSN - DE/Munich)
[mailto:[email-masked]] 
发送时间: 2011年3月7日 18:06
收件人: ext Ning Zong; ext zhangyunfei; [email-masked]
主题: RE: [ppsp] Draft-ietf-ppsp-req-01

Hi Ning Zong,

I do not agree, that basic QoS issues should not be a normative requirement
for PPSP system. I think they are essential to this services.

what about the proposal to include a section Quality of Service
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 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 seems to be not acceptable.”

QoS.REQ-3: 

“The user should receive an error free copy of the original streaming. This
can be done with addition of redundancy and the usage of packet
retransmission. But the additional delay has to be taken into account.”

What do you think about?

BR

Christian

 

From: ext Ning Zong [mailto:[email-masked]] 
Sent: Friday, February 25, 2011 1:28 AM
To: Schmidt, Christian 1. (NSN - DE/Munich); 'ext zhangyunfei';
[email-masked]
Subject: 答复: [ppsp] Draft-ietf-ppsp-req-01

Hi, Schmidt,

Your suggestion is good, although I think this new text could be in
explanatory text rather than in the formal requirement body.

BTW, I have post a new revision -02 and forward the message to the list, but
it seems that it doesn’t come out. So I attached the link to the new
version as below

BR,

Ning Zong

发件人: [email-masked] [mailto:[email-masked]] 代表 Schmidt,
Christian 1. (NSN - DE/Munich)
发送时间: 2011年2月24日 20:56
收件人: ext zhangyunfei; [email-masked]
主题: [ppsp] Draft-ietf-ppsp-req-01

Hi Yunfei,

We should add:

Proposal:

What do you think about?

Best Regards

Christian

---

From: "Schmidt, Christian 1. (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 8 Mar 2011 07:41:38 +0100

Hi Ning Zong,

yes, I can imagine influences to both.

In case of bad quality at the receiving side, e.g. temporary low bandwidth – due to mobility, or improved mobile condition the peer protocol could provide related information to the streaming source.

In case of bad quality, resulting from an sub-optimal source peer selection (e.g. with insufficient uplink capacity or general too high end-to-end delay) the receiving peer can inform the tracker via the tracker protocol about this situation and request a new peer selection. The tracker can use this information for new source selection requests from other peers.

Best Regards

Christian 

From: ext Ning Zong [mailto:[email-masked]] 
Sent: Tuesday, March 08, 2011 2:40 AM
To: Schmidt, Christian 1. (NSN - DE/Munich); 'ext zhangyunfei'; [email-masked]
Subject: 答复: [ppsp] Draft-ietf-ppsp-req-01

Hi, Schmidt,

I agree that these requirements of QoS are important to P2P streaming system. However, I still don’t see how these QoS requirements impact the design of Tracker & Peer Protocol, bearing in mind that our scope is not developing a P2P streaming system. Instead, IMO, these requirements could be addressed by some video transmission protocols such as those developed in AVT WG.

Could you give some examples on how these QoS issue will apply to Tracker & Peer Protocol?

Thanks.

BR,

Ning Zong

发件人: Schmidt, Christian 1. (NSN - DE/Munich) [mailto:[email-masked]] 
发送时间: 2011年3月7日 18:06
收件人: ext Ning Zong; ext zhangyunfei; [email-masked]
主题: RE: [ppsp] Draft-ietf-ppsp-req-01

Hi Ning Zong,

QoS.REQ-1:

QoS.REQ-2: 

QoS.REQ-3: 

What do you think about?

BR

Christian

 

Hi, Schmidt,

BR,

Ning Zong

Hi Yunfei,

We should add:

Proposal:

What do you think about?

Best Regards

Christian

---

From: Ning Zong <[email-masked]>
Date: Wed, 16 Mar 2011 08:49:05 +0800

Hi Christian

Sorry for the late reply. I believe what you have described are good for
PPSP QoS.

We do have such description that PPSP protocol MAY support including
requesting peer’s preference for QoS purpose (see TP.REQ-3). But we don’t
make it as formal requirement since the application can handle this – for
example, application can try more peers once bad quality is detected.

Anyway, we can put this QoS issue in our presentation slides and discuss on
the Prague meeting.

BR,

Ning Zong

发送时间: 2011年3月8日 14:42

Hi Ning Zong,

In case of bad quality at the receiving side, e.g. temporary low bandwidth
– due to mobility, or improved mobile condition the peer protocol could
provide related information to the streaming source.

In case of bad quality, resulting from an sub-optimal source peer selection
(e.g. with insufficient uplink capacity or general too high end-to-end
delay) the receiving peer can inform the tracker via the tracker protocol
about this situation and request a new peer selection. The tracker can use
this information for new source selection requests from other peers.

Best Regards

Christian 

Hi, Schmidt,

Thanks.

BR,

Ning Zong

Hi Ning Zong,

QoS.REQ-1:

QoS.REQ-2: 

QoS.REQ-3: 

What do you think about?

BR

Christian

 

Hi, Schmidt,

BR,

Ning Zong

Hi Yunfei,

We should add:

Proposal:

What do you think about?

Best Regards

Christian