Subject: Re: [ppsp] New Version Notification for draft-gu-ppsp-peer-protocol-03.txt

From: Rui Cruz <[email-masked]>
Date: Tue, 1 Nov 2011 13:38:48 +0000

Indeed, I suppose nothing prevents using HTTP/XML over UDP, as messages typically fit in UDP datagrams and the methods used for requests are POST.
In the draft the transport protocol to be used for the signaling was not specified and it is open to discussion.

---------------------------
Best Regards,

Prof. Rui Santos Cruz
Chairman
IEEE Portugal Section
Av. Prof. Dr. Aníbal Cavaco Silva, IST-TagusPark, Office 1-5, 2744-016 Porto Salvo, Portugal
+351 214 233 200 (ext 5044), +351.939 060 939 (mobile)
[email-masked] 
[email-masked]
[email-masked]
www.ieee-pt.org
Advancing technology for humanity.

On 01/11/2011, at 01:55, [email-masked] wrote:

> 
> I think XML over UDP is also a good option.
> 
> BR 
> Lichun
> 
> 
> [email-masked] 写于 2011-11-01 09:21:28:
> 
> > Hi,
> > 
> > We have updated the PPSP Tracker Protocol draft, corresponding to 
> > the merge of the former drafts from Gu and Cruz. 
> > 
> > This version mainly focus on the messages exchanged between peers, 
> > but leave the encoding format into Appendix since using binary or 
> > HTTP/XML as container is still under dispute.
> > 
> > Please let us know your comments and suggestions.
> > 
> > Thanks.
> > 
> > Jinwei
> > 
> > -----邮件原件-----
> > 发件人: [email-masked] [mailto:[email-masked]] 
> > 发送时间: 2011年10月31日 19:04
> > 收件人: Xiajinwei
> > 抄送: Xiajinwei; Yingjie Gu(yingjie); [email-masked]; joao.
> > [email-masked]; [email-masked]; [email-masked]
> > 主题: New Version Notification for draft-gu-ppsp-peer-protocol-03.txt
> > 
> > A new version of I-D, draft-gu-ppsp-peer-protocol-03.txt has been 
> > successfully submitted by Jinwei Xia and posted to the IETF repository.
> > 
> > Filename:    draft-gu-ppsp-peer-protocol
> > Revision:    03
> > Title:       Peer Protocol
> > Creation date:    2011-10-31
> > WG ID:       Individual Submission
> > Number of pages: 31
> > 
> > Abstract:
> >    This document presents the architecture of the PPSP Peer protocol
> >    outlining the functional entities, message flows and message
> >    processing instructions, with the respective parameters.  The PPSP
> >    Peer Protocol proposed in this document extends the capabilities of
> >    PPSP to support adaptive and scalable video and 3D video, for Video
> >    On Demand (VoD) and Live video services.  The protocol messages
> >    formal syntax and semantics, methods, and formats are presented for
> >    both Binary and HTTP/XML encoded formats.
> > 
> >                                                                              
> > 
> > 
> > The IETF Secretariat
> > _______________________________________________
> > ppsp mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/ppsp
> 
> --------------------------------------------------------
> 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.
> _______________________________________________
> ppsp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ppsp

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 9 Nov 2011 15:36:29 +0000

[Speaking as individual]
Hi all,

I guess HTTP is only defined to run over TCP and not over UDP for various reasons, e.g.,

-          HTTP messages exceed the size of an UDP datagram, except in some corner cases;

-          There is no reliable transport, flow and congestion control in UDP;

-          A HTTP GET can result in a very large 200 OK message.

This definitely rules out HTTP over UDP.

To be honestly, I’m puzzled why HTTP should the choice for the communication between peers? It is:

-          a client server protocol, though we need a bidirectional protocol which no clear client and server roles. Extensions to HTTP to let servers send asynchronous messages are on the way, see the BiDirectional or Server-Initiated HTTP (hybi) working group (http://datatracker.ietf.org/wg/hybi/charter/). However, this is not yet finished;

-          it has a considerable overhead caused by the HTTP headers on the wire, compared to the message content (e.g., chunk maps); A good example is google’s work on spdy, which has the goal to reduce the HTTP headers. See this link (http://dev.chromium.org/spdy/spdy-whitepaper): “Uncompressed request and response headers. Request headers today vary in size from ~200 bytes to over 2KB.”;

-          it has a considerable overhead when implementing it, e.g., code size. I know that many p2p clients have a HTTP stack, but it should not be mandatory to implement IMO.

Reusing existing protocols is a good idea, but I have the feeling that we are stretching it a bit too much in this case.

My few cents

  Martin

[email-masked]<mailto:[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: [email-masked] [mailto:[email-masked]] On Behalf Of Rui Cruz
Sent: Tuesday, November 01, 2011 2:39 PM
To: [email-masked]
Cc: Rui Cruz; [email-masked]; [email-masked]
Subject: Re: [ppsp] New Version Notification for draft-gu-ppsp-peer-protocol-03.txt

Prof. Rui Santos Cruz
Chairman
IEEE Portugal Section
Av. Prof. Dr. Aníbal Cavaco Silva, IST-TagusPark, Office 1-5, 2744-016 Porto Salvo, Portugal
+351 214 233 200 (ext 5044), +351.939 060 939 (mobile)
[email-masked]<x-msg://127/[email-masked]>
[email-masked]<x-msg://127/[email-masked]>
[email-masked]<x-msg://127/[email-masked]>
www.ieee-pt.org<http://www.ieee-pt.org/>
Advancing technology for humanity.

On 01/11/2011, at 01:55, [email-masked]<mailto:[email-masked]> wrote:

BR
Lichun

[email-masked]<mailto:[email-masked]> 写于 2011-11-01 09:21:28:

> 发件人: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
> 发送时间: 2011年10月31日 19:04
> 收件人: Xiajinwei
> 抄送: Xiajinwei; Yingjie Gu(yingjie); [email-masked]<mailto:[email-masked]>; joao.
> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
_______________________________________________
ppsp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ppsp

---

From: Rui Cruz <[email-masked]>
Date: Sat, 12 Nov 2011 18:10:41 +0000

Hi Martin,
see my comments inline.

Cumprimentos/Regards,
Rui Cruz

Sent from my iPad2

> This definitely rules out HTTP over UDP.

Well, UPnP uses HTTP over UDP in discovery messages.
Using HTTP/XML encoding for signaling, results mostly in small sized messages, as the main information is in the body and not in the resource and header, and the total is typically smaller than the size of a UDP datagram.
About reliability and congestion control, that is correct, therefore the preference on using TCP when reliability is required.
The protocol we designed uses POST messages for requests and takes advantage of getting the replies with the requested data as payload on the body of 200 OK. The reply would have to be transported anyway, so why not on the body of a 200 OK?

> -          it has a considerable overhead when implementing it, e.g., code size. I know that many p2p clients have a HTTP stack, but it should not be mandatory to implement IMO.

I would say that HTTP is a request/reply protocol between hosts. Anyway, for a Streaming environment, what a media Player interfaces is with "streaming server nodes", and so, we may think of Peers as the Streaming servers for a Client Media Player.
So, any Peer is in fact a provider (server) entity for other interested Peers, but also a consumer (client) of the media available in the other Peers.
Considering streaming of segmented media, the chunks have quite a large size, ranging from as low as 5KiB to ~200 KiB (typical in scalable coding) for media chunk playout duration of ~2 seconds (for High Quality videos). The HTTP header size (and request body)  is then comparatively small.
Additionally, for these media chunk sizes (200+ KiB), a high quality non scalable video needs around one request every 2 seconds (not considering any special strategy for piece picking). This is quite different from the typical implementations of streaming via BitTorrent-like techniques, that need a quite large amount of requests per second for the very same video playout duration.
For scalable media, this is an advantage for the strategy of requesting the layers of a chunk up to a certain quality (eventually the maximum) in the very same time window. Additionally, and for scalable media, the probability of smooth playout without rebuffering is very high.
This is one of the reasons for the adoption of HTTP Adaptive Streaming techniques from 3GPP and ISO, in special for mobile environment. There are already applications for Live Streaming using HTTP for smartphones and aTablets, over 3G or Wi-Fi, providing a high quality of experience to the user. An example is the Bloomberg App for the iPad.

> [email-masked]
>

---

From: Njaal Borch <[email-masked]>
Date: Sat, 12 Nov 2011 21:12:52 +0100

Hi Rui, Martin and all,

I most definately agree with Martin that HTTP is neither suited for UDP
transport, nor is it a good choice for a P2P protocol.  A peer in a P2P
network does not act as a server to one node and a client of another, it is
(or should be) a node with likely a partially overlapping interest of data
with some resources to exchange.  In other words, there is an exchange of
data, not a (double) producer-consumer relationship. The difference in
these two views of what a node is does account for a lot of the discussion
I belive.

You can't design for traffic to be largely one way.  You must think about
incentives, and if they are not integrated in the protocol (like
tit-for-tat), it must be thought about.  As nodes cannot be trusted, you
must have integrity checking.  If you can only check large blocks for
integrity checks, you are making the protool very easy to attack.  You also
can't say that your solution makes fewer requests, because the chunk size
is vastly bigger - it is a reason why chunk sizes in e.g. live BT protocols
is small.  Lots and lots of nodes have very slow uplinks - meaning that if
you are a bit unlucky, a node can easily spend several minutes uploading
200kb of data.  If you design only for fast nodes, you basically dismiss of
all ADSL and a lot of cable users too, not to mention all types of mobile
nodes which are so far all asynchronous as far as I've seen.  Allowing slow
nodes to participate by providing data for longer is a very nice way to
allow them not to be a massive burden on the P2P network.

In other words, a P2P protocol *must be designed as a P2P protocol*, even
if it has a main focus on streaming.  I feel strongly that you are starting
from scratch in the design of this protocol instead of taking in all the
knowledge that is now available after several years of various P2P
protocols and even several distinct P2P streaming protocols.  I frankly
think this proposal is more in line with a streaming Napster than something
that can power cost efficient media distribution to millions of people in
the next decade.

Regards,
Njaal
 On Nov 12, 2011 7:11 PM, "Rui Cruz" <[email-masked]> wrote:

>  [Speaking as individual]****
>
> Hi all,****
>
> ** **
>
> I guess HTTP is only defined to run over TCP and not over UDP for various
> reasons, e.g.,****
>
> -          HTTP messages exceed the size of an UDP datagram, except in
> some corner cases;****
>
> -          There is no reliable transport, flow and congestion control in
> UDP;****
>
> -          A HTTP GET can result in a very large 200 OK message.****
>
> ** **
>
> Using HTTP/XML encoding for signaling, results mostly in small sized
> messages, as the main information is in the body and not in the resource
> and header, and the total is typically smaller than the size of a UDP
> datagram.
> About reliability and congestion control, that is correct, therefore the
> preference on using TCP when reliability is required.
> The protocol we designed uses POST messages for requests and takes
> advantage of getting the replies with the requested data as payload on the
> body of 200 OK. The reply would have to be transported anyway, so why not
> on the body of a 200 OK?
>
> ****
>
> ** **
>
> To be honestly, I’m puzzled why HTTP should the choice for the
> communication between peers? It is:****
>
> -          a client server protocol, though we need a bidirectional
> protocol which no clear client and server roles. Extensions to HTTP to let
> servers send asynchronous messages are on the way, see the BiDirectional or
> Server-Initiated HTTP (hybi) working group (
> http://datatracker.ietf.org/wg/hybi/charter/). However, this is not yet
> finished;****
>
> -          it has a considerable overhead caused by the HTTP headers on
> the wire, compared to the message content (e.g., chunk maps); A good
> example is google’s work on spdy, which has the goal to reduce the HTTP
> headers. See this link (http://dev.chromium.org/spdy/spdy-whitepaper):
> “Uncompressed request and response headers. Request headers today vary in
> size from ~200 bytes to over 2KB.”;****
>
> -          it has a considerable overhead when implementing it, e.g.,
> code size. I know that many p2p clients have a HTTP stack, but it should
> not be mandatory to implement IMO.
>
>
> I would say that HTTP is a request/reply protocol between hosts. Anyway,
> for a Streaming environment, what a media Player interfaces is with
> "streaming server nodes", and so, we may think of Peers as the Streaming
> servers for a Client Media Player.
> So, any Peer is in fact a provider (server) entity for other interested
> Peers, but also a consumer (client) of the media available in the other
> Peers.
> Considering streaming of segmented media, the chunks have quite a large
> size, ranging from as low as 5KiB to ~200 KiB (typical in scalable coding)
> for media chunk playout duration of ~2 seconds (for High Quality videos).
> The HTTP header size (and request body)  is then comparatively small.
> Additionally, for these media chunk sizes (200+ KiB), a high quality non
> scalable video needs around one request every 2 seconds (not considering
> any special strategy for piece picking). This is quite different from the
> typical implementations of streaming via BitTorrent-like techniques, that
> need a quite large amount of requests per second for the very same video
> playout duration.
> For scalable media, this is an advantage for the strategy of requesting
> the layers of a chunk up to a certain quality (eventually the maximum) in
> the very same time window. Additionally, and for scalable media, the
> probability of smooth playout without rebuffering is very high.
> This is one of the reasons for the adoption of HTTP Adaptive Streaming
> techniques from 3GPP and ISO, in special for mobile environment. There are
> already applications for Live Streaming using HTTP for smartphones and
> aTablets, over 3G or Wi-Fi, providing a high quality of experience to the
> user. An example is the Bloomberg App for the iPad.
>
> ****
>
> ** **
>
> Reusing existing protocols is a good idea, but I have the feeling that we
> are stretching it a bit too much in this case. ****
>
> ** **
>
> My few cents****
>
> ** **
>
>   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:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Rui Cruz
> *Sent:* Tuesday, November 01, 2011 2:39 PM
> *To:* [email-masked]
> *Cc:* Rui Cruz; [email-masked]; [email-masked]
> *Subject:* Re: [ppsp] New Version Notification for
> draft-gu-ppsp-peer-protocol-03.txt****
>
> ** **
>
> Indeed, I suppose nothing prevents using HTTP/XML over UDP, as messages
> typically fit in UDP datagrams and the methods used for requests are POST.
> ****
>
> In the draft the transport protocol to be used for the signaling was not
> specified and it is open to discussion.****
>
>
> ---------------------------****
>
> Best Regards,
>
> *Prof. Rui Santos Cruz**
> *Chairman
> *IEEE Portugal Section**
> *Av. Prof. Dr. Aníbal Cavaco Silva, IST-TagusPark, Office 1-5, 2744-016
> Porto Salvo, Portugal
> Advancing technology for humanity.****
>
> ** **
>
> On 01/11/2011, at 01:55, [email-masked] wrote:****
>
>
>
> ****
>
>
> > https://www.ietf.org/mailman/listinfo/ppsp****
>
> --------------------------------------------------------****
>
> 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.****
>
> https://www.ietf.org/mailman/listinfo/ppsp****
>
> ** **
>

---

From: Csaba Kiraly <[email-masked]>
Date: Sun, 13 Nov 2011 02:18:01 +0100

Hi Martin, Hi Rui,

On 11/12/2011 07:10 PM, Rui Cruz wrote:
> Hi Martin,
> see my comments inline.
>
> Cumprimentos/Regards,
> Rui Cruz
>
> Sent from my iPad2
>
> On 09/11/2011, at 15:36, Martin Stiemerling <[email-masked] <mailto:[email-masked]>> wrote:
>
>> [Speaking as individual]
>>
>> Hi all,
>>
>> -HTTP messages exceed the size of an UDP datagram, except in some corner cases;
>>
>> -There is no reliable transport, flow and congestion control in UDP;
>>
>> -A HTTP GET can result in a very large 200 OK message.
>>
This can be done, although it is questionable what sense it makes. HTTP is defined in a reliable stream context. If you know for sure that you use only a very restricted subset of HTTP features (only a request and a response, only what fits in one packet, etc.), it can even work, but there are so many other things that work, why chose this specific one? I know it was just an example, but it sounds like a workaround.

I did not read through the UPnP docs, but I think it is in fact a workaround that fakes HTTP, but one side is not a standards compliant HTTP server, and the other side is not a standards compliant HTTP client. These entities only use some HTTP like headers, but then they do not comply. I should emphasize that I did not check carefully, but if this is the case, this is really bad protocol design. Why one writes HTTP/1.1 in a header when in fact it can't comply with it?

> Using HTTP/XML encoding for signaling, results mostly in small sized messages, as the main information is in the body and not in the resource and header, and the total is typically smaller than the…
Wait a second. You mean that putting contect encoded with XML over HTTP over UDP is smaller than content over UDP? I think I don't understand this statement. The overhead might be small, it might even be irrelevant in some use cases (like you say below), but it is an overhead. You will not spare bits on the wire by adding HTTP and XML.

>> To be honestly, I'm puzzled why HTTP should the choice for the communication between peers? It is:
>>
>> -a client server protocol, though we need a bidirectional protocol which no clear client and server roles. Extensions to HTTP to let servers send asynchronous messages are on the way, see the BiDirectional or Server-Initiated HTTP (hybi) working group (http://datatracker.ietf.org/wg/hybi/charter/). However, this is not yet finished;
>>
>> -it has a considerable overhead caused by the HTTP headers on the wire, compared to the message content (e.g., chunk maps); A good example is google's work on spdy, which has the goal to reduce the HTTP headers. See this link (http://dev.chromium.org/spdy/spdy-whitepaper): "Uncompressed request and response headers. Request headers today vary in size from ~200 bytes to over 2KB.";
>>
>> -it has a considerable overhead when implementing it, e.g., code size. I know that many p2p clients have a HTTP stack, but it should not be mandatory to implement IMO.
>>
>

I do not exactly understand how scalable media comes in the picture, it can work with HTTP or without, it seems to be an orthogonal issue. From what you say here it seems that using HTTP is not such a big issue in your specific system design (which is largely different from many other P2P streaming system designs). It works, and it even works well.
My question is: what do you gain by using HTTP and not something else? IMHO other systems that are not using HTTP are working well too. These systems might use different chunk sizes, large or small, and they are still not bottlenecked by HTTP, simply because they do not use it. There are also designs that are using one-way notification messages that doesn't require a response. I do not see how these could be mapped over HTTP without performance drawbacks.  So, my second question is: does your design need any specific feature of HTTP such that a reuse of HTTP is necessary?

Turning back to the previous point: if you look at these entities as HTTP servers and clients, you need to be sure to make a nice compliant implementation of an HTTP server and client. At first it sounds like a non-issue, but doing it well over UDP doesn't sound like something easy, especially if there are no benefits. Even over TCP, defining protocol behavior might get quite complicated if you have to think of all the corner cases HTTP offers.

Having said all this, I'm not against the optional use of HTTP. However, I think it is better to differentiate encoding options for the messaging primitives from transport options. There might e.g. be 2 encoding options (binary and XML), and a number of transport options: reliable stream, like TCP; unreliable datagram, like UDP. There might even be a third one that maps the protocol over the more restrictive request/response model of HTTP. However, doing this latter correctly might get quite cumbersome, since it should detail the handling of various HTTP headers,  HTTP options, etc.

Just my 2c
Csaba

---

From: Martin Stiemerling <[email-masked]>
Date: Tue, 29 Nov 2011 15:53:56 +0000

[speaking as individual contributor and not as chair of the PPSP WG]

Hi Rui,

From: Rui Cruz [mailto:[email-masked]]
Sent: Saturday, November 12, 2011 7:11 PM
To: Martin Stiemerling
Cc: Rui Cruz; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [ppsp] New Version Notification for draft-gu-ppsp-peer-protocol-03.txt

Hi Martin,
see my comments inline.
Cumprimentos/Regards,
Rui Cruz

Sent from my iPad2

On 09/11/2011, at 15:36, Martin Stiemerling <[email-masked]<mailto:[email-masked]>> wrote:
[Speaking as individual]
Hi all,

True, and this is not the standardized way of HTTP, but a hack in upnp.

HTTP is not an encoding scheme.
HTTP headers are still there, even though you just send a single bit in the entity body of the HTTP message.
There is nothing in HTTP which prevents sending HTTP messages which are larger than a UDP datagram. Please note also that the minimal requirement for the MTU of IPv4 is “Every internet module must be able to forward a datagram of 68
    octets without further fragmentation” RFC 791.
I know that the links today have larger MTUs, but this raises the point what the assumption of the MTU on a path is and how this impacts the assumption about the size of an UDP datagram…

I do not see that we need reliable transport of chunks between two peers, but we need congestion control.

That view is correct, but it concerns only the view between the media client and the serving peers for this media client. It does not related to the internals of the p2p protocol.

What if I decide to go for 1 Kilobyte chunks?
What if I just sent chunk maps or any other signaling messages back and forth?

The trouble I see is that you have only your scenario in mind. I’m not sure that your assumptions hold true if you switch to MDC.

And? I do not get the point you trying to raise.

  Martin

My few cents

  Martin

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Rui Cruz
Sent: Tuesday, November 01, 2011 2:39 PM
To: [email-masked]<mailto:[email-masked]>
Cc: Rui Cruz; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [ppsp] New Version Notification for draft-gu-ppsp-peer-protocol-03.txt

Prof. Rui Santos Cruz
Chairman
IEEE Portugal Section

BR
Lichun