Subject: [ppsp] PPSP Requirements: PPSP.TP.REQ-4 (number of peers and downloading bandwidth)

From: Martin Stiemerling <[email-masked]>
Date: Wed, 27 Oct 2010 13:25:54 +0000

Hi,

A clarifying question to the requirements draft's PPSP.TP.REQ-4. It says:
PPSP.TP.REQ-4: The tracker request message MAY include parameter of
   requested number of downloading peers or preferred downloading
   bandwidth.

First, wouldn't it be better to specify:
"The tracker request message SHOULD allow to include parameters set by the peer to further refine the request."

I guess that this is the actual intention of the requirements. The next requirements below would be a refinement of the above requirement or examples:

Second, one more detailed requirement could be"
"The tracker request message SHOULD allow to include parameters which denote the number of peers queried for."

Another requirement could be:
"The tracker request message SHOULD allow to include parameters which denotes the minimum theoretical upload bandwidth of a peer."

 Martin

[email-masked]

NEC Laboratories Europe - Network Research Division
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014

---

From: "Rahman, Akbar" <[email-masked]>
Date: Wed, 27 Oct 2010 09:35:07 -0400

Hi Martin,

I agree with your comments.  Also please note that I have previously
raised some other issues on the requirements for which I am still
waiting for some feedback on (see attached link)

http://www.ietf.org/mail-archive/web/ppsp/current/msg00720.html

Sincerely,

Akbar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Martin Stiemerling
Sent: Wednesday, October 27, 2010 9:26 AM
To: [email-masked]
Subject: [ppsp] PPSP Requirements: PPSP.TP.REQ-4 (number of peers and
downloading bandwidth)

Hi,

A clarifying question to the requirements draft's PPSP.TP.REQ-4. It
says:
PPSP.TP.REQ-4: The tracker request message MAY include parameter of
   requested number of downloading peers or preferred downloading
   bandwidth.

First, wouldn't it be better to specify:
"The tracker request message SHOULD allow to include parameters set by
the peer to further refine the request."

I guess that this is the actual intention of the requirements. The next
requirements below would be a refinement of the above requirement or
examples:

Second, one more detailed requirement could be"
"The tracker request message SHOULD allow to include parameters which
denote the number of peers queried for."

Another requirement could be:
"The tracker request message SHOULD allow to include parameters which
denotes the minimum theoretical upload bandwidth of a peer."

 Martin

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
[email-masked]
https://www.ietf.org/mailman/listinfo/ppsp

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 27 Oct 2010 13:53:07 +0000

Hi Akbar,

Just browsed the points and I tend to agree with most points. 

Mobility isn't covered at all in the requirements and not even reflected any of them.

For the battery one - I guess it would make sense to say:
Peers SHOULD be able to add specific parameters to their tracker request

and to refine it in separate step to "this may include battery status information."

Thanks,

  Martin

> From: Rahman, Akbar [mailto:[email-masked]]
> Sent: Wednesday, October 27, 2010 3:35 PM
> To: Martin Stiemerling
> Cc: [email-masked]
> Subject: RE: [ppsp] PPSP Requirements: PPSP.TP.REQ-4 (number of peers
> and downloading bandwidth)
> 
> Hi Martin,
> 
>

---

From: "Rahman, Akbar" <[email-masked]>
Date: Wed, 27 Oct 2010 10:28:16 -0400

Thanks, Martin.

I will make your suggested changes for the battery status in the next
revision of my draft.  Or better yet, the PPSP Requirement draft will
incorporate your and my suggestions for adding the mobility requirements
into their WG draft (and I will no longer have to maintain my separate
draft)!

See you in Beijing.

Akbar

-----Original Message-----
From: Martin Stiemerling [mailto:[email-masked]] 
Sent: Wednesday, October 27, 2010 9:53 AM
To: Rahman, Akbar
Cc: [email-masked]
Subject: RE: [ppsp] PPSP Requirements: PPSP.TP.REQ-4 (number of peers

Hi Akbar,

Mobility isn't covered at all in the requirements and not even reflected
any of them.

and to refine it in separate step to "this may include battery status
information."

Thanks,

  Martin

---

From: Ning Zong <[email-masked]>
Date: Thu, 28 Oct 2010 08:33:02 +0800

Hi, Akbar and Martin
Thank you very much for contributing to the requirement draft.
My suggestion is that I will put these requirement changes to our
presentation slides used on Beijing meeting so that we can get group
consensus about how to incorporate the suggested text into PPSP requirement
drafts.
Although personally I agree with some of the changes, we need to get group
consensus before adopting them into the WG draft, right?
Sorry for the late response and, hope to see you all in Beijing.

BR,
Ning Zong

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Rahman, Akbar
Sent: Wednesday, October 27, 2010 10:28 PM
To: Martin Stiemerling
Cc: [email-masked]
Subject: Re: [ppsp] PPSP Requirements: PPSP.TP.REQ-4 (number of peers
anddownloading bandwidth)

Thanks, Martin.

See you in Beijing.

Akbar

-----Original Message-----
From: Martin Stiemerling [mailto:[email-masked]] 
Sent: Wednesday, October 27, 2010 9:53 AM
To: Rahman, Akbar
Cc: [email-masked]
Subject: RE: [ppsp] PPSP Requirements: PPSP.TP.REQ-4 (number of peers

Hi Akbar,

Thanks,

  Martin

---

From: "Schmidt, Christian 1. (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 29 Oct 2010 09:58:33 +0200

Hi,

here some questions, remarks concerning 4.2.  PPSP Tracker Protocol
Requirements:

   PPSP.TP.REQ-7: The PPSP tracker MAY generate the peer list with the
   help of traffic optimization services, e.g.  Alto.

How does this influence the PPSP Tracker protocol? 
- Do you want to include a request parameter to allow / disallow this
Alto approach for a certain request?
- Do you want to provide an information to the requesting peer, that the
list was generated with the help of an Alto server?
PS: I assume, for contacting the Alto Server, the Alto Protocol is used.

   PPSP.TP.REQ-8: The peer status report (update) message MAY have the
   option to carry streaming status of the peer, including online time,
   link status, peer capability and other streaming parameters of the
   peer.  Therefore, the tracker is able to select better candidate
   peers for streaming without the help of other traffic optimization
   services.

Should we also mention the fact, that 
- it is a mobile peer
- the peer is connected via NAT
- peer information about QoS values?
What do you think about?

BR
Christian

---

From: Ning Zong <[email-masked]>
Date: Fri, 29 Oct 2010 17:39:59 +0800

Hi, Christian,

Thank you for reviewing the draft.
Please see my reply below inline.

-----Original Message-----
From: Schmidt, Christian 1. (NSN - DE/Munich)
[mailto:[email-masked]] 
Sent: Friday, October 29, 2010 3:59 PM
To: ext Ning Zong
Cc: [email-masked]
Subject: PPSP Requirments for tracker

Hi,

How does this influence the PPSP Tracker protocol? 
- Do you want to include a request parameter to allow / disallow this
Alto approach for a certain request?
[ZN]:  I think the traffic optimization service will (optionally) happen
between tracker and optimization server (like current architecture defined
by ALTO), which means that the requesting peer is not aware of the traffic
optimization service, but only receive a list of selected peers. The
decision of allow / disallow optimization approach can be done on tracker
based on some policy and/or certain granularity, such as swarm, certain
peer(s).
- Do you want to provide an information to the requesting peer, that the
list was generated with the help of an Alto server?
[ZN]: see above.
PS: I assume, for contacting the Alto Server, the Alto Protocol is used.
[ZN]: I agree.

Should we also mention the fact, that 
- it is a mobile peer
- the peer is connected via NAT
- peer information about QoS values?
What do you think about?
[ZN]: Yes, they are all possible options. But we need to carefully handle
them, e.g. mobile peer will have some unique features for streaming rather
than just acting like "mobile" nodes.

BR
Christian