Internet DRAFT - draft-huang-ppsp-extended-tracker-protocol
draft-huang-ppsp-extended-tracker-protocol
PPSP Rachel Huang
INTERNET-DRAFT Huawei
Intended Status: Standards Track Rui Cruz
Expires: September 10, 2015 Mario S. Nunes
INESC-ID/INOV
Joao P. Taveira
IST/INOV
Lingli Deng
China Mobile
March 9, 2015
PPSP Tracker Protocol-Extended Protocol
draft-huang-ppsp-extended-tracker-protocol-08
Abstract
This document specifies an extension to the PPSP Tracker Protocol -
Base Protocol, which complements the core messages of the protocol
with Request-Response enhancements and usages, and with a new
DISCONNECT Protocol-level message. These enhancements and usages are
related with the exchange of meta information between trackers and
peers, such as initial offer/request of participation in multimedia
content streaming, content information, peer lists, reports of
activity and status, and graceful disconnection from the network.
The extension is retro-compatible with the PPSP-TP Base Protocol.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
Huang, et al. Expires September 10, 2015 [Page 1]
INTERNET DRAFT PPSP-TP/1.1 March 9, 2015
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Huang, et al. Expires September 10, 2015 [Page 2]
INTERNET DRAFT PPSP-TP/1.1 March 9, 2015
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Extended Tracker Protocol Overview . . . . . . . . . . . . . . 5
4.1. Request-Response Extension . . . . . . . . . . . . . . . . 5
4.2. Protocol-level Extension . . . . . . . . . . . . . . . . . 6
4.3. Usage of Extended Request Messages . . . . . . . . . . . . 6
4.4. Extended Tracker Transaction State Machine . . . . . . . . 7
4.4.1. Normal Operation . . . . . . . . . . . . . . . . . . . 9
4.4.2. Error Conditions . . . . . . . . . . . . . . . . . . . 10
5 Extended Tracker Protocol Specification . . . . . . . . . . . . 10
5.1. Request/Response Syntax and Format . . . . . . . . . . . . 10
5.3. Compatibility with the Base Tracker Protocol . . . . . . . 12
5.4. Negotiation of Chunk Addressing Methods . . . . . . . . . . 13
5.5. Request/Response Processing . . . . . . . . . . . . . . . . 14
5.5.1. Enhanced FIND Request . . . . . . . . . . . . . . . . . 14
5.5.2. Enhanced STAT_REPORT Request . . . . . . . . . . . . . 14
5.5.3. DISCONNECT Request . . . . . . . . . . . . . . . . . . 14
6. Error and Recovery Conditions . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 15
10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1 Normative References . . . . . . . . . . . . . . . . . . . 15
10.2 Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Huang, et al. Expires September 10, 2015 [Page 3]
INTERNET DRAFT PPSP-TP/1.1 March 9, 2015
1. Introduction
The PPSP Tracker Protocol is one of the Peer-to-Peer Streaming
Protocol which specifies standard format/encoding of information and
messages between PPSP peers and PPSP trackers. Based on the
requirements defined in RFC 6972 [RFC6972], the base tracker protocol
specified in [I-D.ietf-ppsp-base-tracker-protocol] has provided the
basic core messages to be exchanged between trackers and peers in
order to carry out some fundamental operations. The core messages
are mandatory, covering most basic and universal use cases, and MUST
be implemented in all PPSP-based streaming systems.
This document specifies extensions to the base core messages of
[I-D.ietf-ppsp-base-tracker-protocol] with enhancements in
request/responses and new optional request message, providing new
usages in some scenarios. The extension of the base protocol is
retro-compatible with the PPSP-TP Base Protocol, and messages using
this specification MUST be safely rejected by trackers not supporting
the extensions to avoid affecting interoperability.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
This draft uses terms defined in [RFC6972] and [I-D.ietf-ppsp-base-
tracker-protocol].
3. Motivation
There are a number of possible usages and issues which may be useful
for discussion and which the base tracker protocol may not be able to
deal with.
1. In the base tracker protocol, the disconnection between peer and
tracker is achieved by a timeout (of periodic STAT_REPORT
messages) which means that trackers lack the ability to timely
free up resources. In some cases when the number of connected
peers is reaching the maximum capacity of a tracker, resources of
the tracker cannot be released immediately even if some peers
leave the swarm, hence resulting in connection failures. This
requires the base tracker protocol to be extended to have a
message providing the ability to notify the tracker that a peer
has left.
2. A peer may have the requirement to start streaming the content
from one specific point of the content timeline. For example,
when the end-user watches only part of a content and decides to
Huang, et al. Expires September 10, 2015 [Page 4]
INTERNET DRAFT PPSP-TP/1.1 March 9, 2015
stop and leave, or pauses for a long time. When the end-user
wants to resume the session he/she expects to continue watching
the content from the point where he/she interrupted. The peer may
then request the tracker to select a subset of peers capable to
provide that specific content scope. In this case, it requires
that the quest for content from neighbor peers should contain the
content scope information and peers should constantly report their
content scope information to the tracker.
4. Extended Tracker Protocol Overview
The extended Tracker Protocol consists of two Request-Response
Extensions (to the FIND and STAT_REPORT Request messages of the Base
Protocol) and one Protocol-level Extension (a new DISCONNECT Request
message).
4.1. Request-Response Extension
In this section, the FIND and STAT_REPORT messages specified in the
base tracker protocol are extended to meet the needs of use case 2
listed in section 3.
FIND: The enhanced FIND Request message allows a peer to request the
tracker for a subset of peers in a swarm but including
specific content scopes, either media content representations
or specific chunks/segments of a media representation in a
swarm, and may also include an updated network address of the
peer. On receiving a FIND message, the tracker selects a
subset of peers satisfying the requesting scope. To create
the peer list, the tracker may also take peer status,
capabilities and peers priority into consideration. Peer
priority may be determined by network topology preference,
operator policy preference, etc. The format and detailed
processing of enhanced CONNECT Request message is presented in
Section 5.2.
STAT_REPORT: The enhanced STAT_REPORT Request message allows the
exchanges of content data information, like chunkmaps, between
an active peer and a tracker. The information can be used by
a tracker as a qualification to select appropriate subsets of
peers in the swarm satisfying specific scopes (in terms of
content). The format and detailed processing of enhanced
CONNECT Request message is presented in Section 5.3.
To present the content data information, the chunk addressing schemes
(section 4 of [I-D.ietf-ppsp-peer-protocol]) are used to support
different ways of identifying chunks and expressing chunk
availability of a peer in a compact fashion. The chunk addressing
Huang, et al. Expires September 10, 2015 [Page 5]
INTERNET DRAFT PPSP-TP/1.1 March 9, 2015
methods for certain content should be recorded in the metadata of the
swarm for the content, and they can be obtained by peers or trackers
during the enrollment and bootstrap stage.
4.2. Protocol-level Extension
A new Request message is introduced in this section to extend those
specified in the base tracker protocol [I-D.ietf-ppsp-base-tracker-
protocol], to meet the needs of issue 1 listed in section 3.
DISCONNECT: The DISCONNECT Request message is used when the peer
intends to no longer participate in all swarms. When
receiving the DISCONNECT Request message from a peer, the
tracker deletes the corresponding activity records related to
the peer (including its status and all content status for the
corresponding swarms). In such a case, the DISCONNECT Request
message will have the same effect of timer expiring
(STAT_REPORT), but providing a graceful disconnection of that
peer from the system.
4.3. Usage of Extended Request Messages
An example of usage of the extended request messages is illustrated
in Figure 1. In that figure a peer starts by connecting to the
system and joining a specific swarm (swarm_a) in SEED mode (step_1).
While active, the peer periodically updates the tracker using
STAT_REPORT messages. Later, the peer CONNECTs to another swarm
(swarm_b) but in LEECH mode, i.e., the end-user intends to watch that
new content while still sharing the first one (step_2). During the
streaming session the peer requests an updated list of peers in that
new swarm to the tracker (step_3). When the end-user wants to leave
the second content, not having even finished watching, the peer sends
a CONNECT message with a "leave" action (step_4) for the
corresponding swarm (swarm_b) but remains sharing the first content
(swarm_a).
But later, the end user wants to continue watching the content he/she
previously left unfinished. So the peer firstly CONNECTs to the
corresponding swarm in LEECH mode, then sends FIND message with the
specific content information scope (step_5). Tracker will find the
group of peers who has the specific content for this peer.
Finally,the peer wants to quit the system completely. It does not
have to send a CONNECT message with a "leave" action one by one. It
just sends the DISCONNECT message to the tracker (step_6), then
tracker will remove all the information for this peer.
Huang, et al. Expires September 10, 2015 [Page 6]
INTERNET DRAFT PPSP-TP/1.1 March 9, 2015
+--------+ +---------+
| Peer | | Tracker |
+--------+ +---------+
| |
step_1 |--CONNECT(swarm_a;SEED)---------->| ---
|<--------------------------OK-----| |
: : |
|--STAT_REPORT(activity)---------->| |
|<--------------------------Ok-----| |
: : |
step_2 |--CONNECT(swarm_b;LEECH)--------->| |
|<-----------------OK+PeerList-----| Base
: : tracker
|--STAT_REPORT(ChunkMap_b)-------->| protocol
|<--------------------------Ok-----| |
: : |
step_3 |--FIND(swarm_b)------------------>| |
|<-----------------OK+PeerList-----| |
: : |
step_4 |--CONNECT(leave swarm_b)--------->| |
|<--------------------------Ok-----| |
: : |
|--STAT_REPORT(activity)---------->| |
|<--------------------------Ok-----| |
: : |
step_5 |--CONNECT(swarm_b;LEECH)--------->| |
|<-----------------OK+PeerList-----| ---
|--FIND(swarm_b;ChunkMap_b)------->| ---
|<-----------------OK+PeerList-----| |
: : |
|--STAT_REPORT(ChunkMap_b)-------->| Extended
|<--------------------------Ok-----| tracker
: : protocol
step_6 |--DISCONNECT(nil)---------------->| |
|<---------------------Ok(BYE)-----| |
: : ---
Figure 1: Example of a session for a extended PPSP-TP.
4.4. Extended Tracker Transaction State Machine
The tracker state machine introduced in the base tracker protocol
[I-D.ietf-ppsp-base-tracker-protocol] is now updated in this
specification to reflect the extensions introduced. An updated "per-
Peer-ID" transaction state machine (Figure 2) is described,
corresponding to the enhanced functionalities and control steps of
the extended tracker protocol. This extended "per-Peer-ID"
Huang, et al. Expires September 10, 2015 [Page 7]
INTERNET DRAFT PPSP-TP/1.1 March 9, 2015
transaction state machine is compatible with the one specified in the
base tracker protocol.
Huang, et al. Expires September 10, 2015 [Page 8]
INTERNET DRAFT PPSP-TP/1.1 March 9, 2015
--------------------------------------------
/ \
| +------------+ +=========+ +======+ |
\-| TERMINATED |<---| STARTED |<---| INIT |<-/
+------------+ +=========+ +======+
(Transient) | (1) \- (start tracker)
V
+-----------+ +-------+ rcv CONNECT
(Transient) | TERMINATE | | START | --------------- (1)
+-----------+ +-------+ strt init timer
rcv DICONNECT ^ |
rcv FIND | |
rcv STAT_REPORT | |
on registration error | v
on action error | +------------+
---------------- (A) +<-----| PEER | (Transient)
stop init timer | | REGISTERED |
snd error | +------------+
| |
| | process swarm actions
on CONNECT Error (B) | | --------------------- (2)
on timeout (C) | | snd OK (PeerList)
on DISCONNECT (5) | / stop init timer
---------------- | / strt track timer
stop track timer | /
clean peer info | |
del registration | | rcv FIND
snd error (B) \ | ---- --------------- (3)
---- \ | / \ snd OK (PeerList)
/ \ \ | | | rst track timer
rcv CONNECT | (4) | | | | |
----------- | v | v v | rcv STAT_REPORT
snd OK \ +==============+ / --------------- (3)
rst track timer ----| TRACKING |---- snd OK response
+==============+ rst track timer
Figure 2: Extended "Per-Peer-ID" Transaction State Machine
The state diagram in Figure 2 illustrates the complete state changes
together with the causing events and resulting actions when
implementing the extensions to the base tracker protocol. Note that
Specific error conditions are not shown in the state diagram.
4.4.1. Normal Operation
Normal operation steps are the same with section 2.3.1 of the base
tracker protocol [I-D.ietf-ppsp-base-tracker-protocol] except adding
Huang, et al. Expires September 10, 2015 [Page 9]
INTERNET DRAFT PPSP-TP/1.1 March 9, 2015
step 5 as follow:
5) While TRACKING, a DISCONNECT message received from the peer, or a
CONNECT message with the action to leave the last swarm, the
tracker stops the "track timer", cleans the information associated
with the participation of the Peer-ID in the the swarm(s) joined,
responds with a successful condition, deletes the registration of
the Peer-ID and transitions to TERMINATED state for that Peer-ID.
4.4.2. Error Conditions
Error condition steps are the same with section 2.3.2 of the base
tracker protocol [I-D.ietf-ppsp-base-tracker-protocol] except the
2nd paragraph of step A:
A) At PEER REGISTERED state, if the Peer ID is considered invalid (in
the case of a CONNECT request, or FIND request, or STAT_REPORT
request, or DISCONNECT request received from an unregistered Peer
ID), the tracker responds with either error codes authentication
required or Forbidden (described in section 4.3 of the base
tracker protocol), transitions to TERMINATE state for that Peer ID
and that state machine instance is destroyed.
5 Extended Tracker Protocol Specification
5.1. Request/Response Syntax and Format
The architecture specified in the base tracker protocol [I-D.ietf-
ppsp-base-tracker-protocol] does not suffers any modification in the
extended protocol. The syntax is identical with some elements
extended to contain new optional attributes:
The request type includes CONNECT, FIND, STAT_REPORT and DISCONNECT,
including a "content" element to the FIND method, that MAY be present
in requests referencing content, i.e., FIND and STAT_REPORT, if the
request includes a content scope.
The extended semantics of the request therefore is described as
follows.
ppsp_tp_string_t ppsp_tp_request_type_t = "CONNECT"
| "FIND"
| "STAT_REPORT"
| "DISCONNECT";
Object {
ppsp_tp_version_t version;
ppsp_tp_request_type_t request_type;
Huang, et al. Expires September 10, 2015 [Page 10]
INTERNET DRAFT PPSP-TP/1.1 March 9, 2015
ppsp_tp_string_t transaction_id;
ppsp_tp_string_t peer_id;
[JSONValue request_data = ppsp_tp_req_connect connect
| ppsp_tp_req_find find
| ppsp_tp_stat_group_t stat_report;]
} ppsp_tp_request;
Note that only when request_type of ppsp_tp_request is "DISCONNECT",
request_data is allowed to be omitted.
The extended value for ppsp_tp_version_t is listed in Table 1 as
follow:
+----------------------------------------------------------+
| ppsp_tp_version_t | Description |
+----------------------------------------------------------+
| 0 | Reserved |
| 1 | PPSP base tracker protocol |
| 2 | PPSP extended tracker protocol |
| | (specified in this document ) |
| 3-255 | Unassigned |
+----------------------------------------------------------+
Table 1: Extended PPSP Tracker Protocol Version Numbers
The semantics for the content information element is described as
follow:
Object {
ppsp_tp_integer_t start_index;
ppsp_tp_integer_t end_index; // 0 means no end
}ppsp_tp_segment_info_t;
Object {
ppsp_tp_integer_t chunk_addressing_method;
ppsp_tp_segment_info_t segments<1..*>;
}ppsp_tp_content_info_t;
The semantics of ppsp_tp_request_find is extend as follows:
Object {
ppsp_tp_string_t swarm_id;
[ppsp_tp_peer_num_t peer_num;]
[ppsp_tp_segment_info_t content_info;]
} ppsp_tp_request_find;
Huang, et al. Expires September 10, 2015 [Page 11]
INTERNET DRAFT PPSP-TP/1.1 March 9, 2015
The semantics of stream_stats is extended as follows:
Object {
ppsp_tp_swarm_id_t swarm_id;
ppsp_tp_integer_t uploaded_bytes;
ppsp_tp_integer_t downloaded_bytes;
ppsp_tp_integer_t available_bandwidth;
ppsp_tp_content_info_t content_info;
}stream_stats;
Currently, the value of chunk_addressing_method is identical to the
addressing method listed in section 7.8 of [I-D.ietf-ppsp-peer-
protocol], as follow:
+--------+---------------------+
| Method | Description |
+--------+---------------------+
| 0 | 32-bit bins |
| 1 | 64-bit byte ranges |
| 2 | 32-bit chunk ranges |
| 3 | 64-bit bins |
| 4 | 64-bit chunk ranges |
| 5-255 | Unassigned |
+--------+---------------------+
Table 1: Chunk Addressing Methods
Implementations MUST support "32-bit chunk ranges" (default) and "64-
bit chunk ranges". When the chunk_addressing_method is 32-bit bins
or 64-bit bins, end_index in SegmentInfo MUST be set to 0. Chunk
addressing methods could be extended to allow new algorithms in
future specifications, e.g., [BFbitmap]. This document does not
extends the semantics and format of Responses.
5.3. Compatibility with the Base Tracker Protocol
Trackers are RECOMMENDED to implement extended tracker protocol to be
compatible with peers using base tracker protocol or peers using
extended tracker protocol. But it is not mandatory. When peers have
different implementations with trackers, following 2 catalogs are
given:
1. Peer (with extended protocol) vs Tracker (with base protocol)
When peers using extended tracker protocol exchange content
information with a tracker only supporting the base tracker protocol,
the tracker would respond with 401 (Unsupported version number)
error_code with an empty message-body (no peer_addr and swarm_result
Huang, et al. Expires September 10, 2015 [Page 12]
INTERNET DRAFT PPSP-TP/1.1 March 9, 2015
attributes), which indicates the messages could not be recognized by
the tracker. In this case, peers MUST stop interacting with the
tracker in extended request messages and use the base tracker
protocol instead.
2. Peer (with base protocol) vs Tracker (with extended protocol)
The tracker is able to handle all the requests from the peer because
all the messages are base tracker protocol messages which could be
perfectly accepted by a tracker implementing extended tracker
protocol.
5.4. Negotiation of Chunk Addressing Methods
Multiple chunk addressing methods could be used in this document to
present content information. But only one of them MUST be used for
one swarm when a peer communicating with a tracker. Before peers
connect to a tracker, they MUST get to know the chunk addressing
methods supported by the swarm. It is out of scope of the tracker
protocol the mechanism used to obtain that information. For example,
it could be some out-of-band methods that obtains that information
from the web portal, together with other information about the
trackers, e.g., IP addresses.
If the chunk addressing method of a swarm can not be supported by a
tracker, the tracker is not suggested to serve that swarm. If the
chunk addressing method contained in requests is not supported by the
swarm controlled by the tracker, the tracker could directly ignore
the content related information.
Huang, et al. Expires September 10, 2015 [Page 13]
INTERNET DRAFT PPSP-TP/1.1 March 9, 2015
5.5. Request/Response Processing
5.5.1. Enhanced FIND Request
This method allows peers to request to the tracker, whenever needed,
a new peer list for the swarm for specific scope of chunks/segments
of a media content representation of that swarm.
The peer MUST properly set the request type to FIND, set the PeerID
with the identifier of the peer, and set the SwarmID with the
identifier of the swarm the peer is interested in. Optionally, in
order to find peers having the specific chunks/segments, the peer may
include the ContentGroup element in the FIND request message to
indicate a specific point in the content timeline.
This message is mainly used for peers in LEECH mode in order to
update the peer list of a swarm. For those requests whose peer_mode
are not set to LEECH, the tracker must respond with 400 (Bad request,
with reason-phrase "Unknown Messages").
In the case of a FIND with a specific scope of a stream content the
request SHOULD include a ContentGroup to specify the segment range of
content Representations.
The response MAY also include a PeerGroup with PeerInfo data that
includes the requesting peer public IP address.
5.5.2. Enhanced STAT_REPORT Request
This message still uses the specifications of the base tracker
protocol [I-D.ietf-ppsp-base-tracker-protocol]. The Stat element has
been extended with one property, "content_info", to allow peers
reporting map of chunks they have. The tracker would not have the
ability to treat the FIND requests for specific content chunks,
unless peers report this kind of information. The corresponding
Response does not need to be extended in this specification.
5.5.3. DISCONNECT Request
This method is used when the peer intends to leave the system and no
longer participate. The tracker SHOULD delete the corresponding
activity records related with the peer in all the swarms (including
its status and all content status).
The peer MUST properly form the Request message, set the request type
to DISCONNECT, set the PeerID with the identifier of the peer, and
randomly generate and set the TransactionID.
Huang, et al. Expires September 10, 2015 [Page 14]
INTERNET DRAFT PPSP-TP/1.1 March 9, 2015
6. Error and Recovery Conditions
This document does not introduces any new error and recovery
conditions. The implementation of error treatment MUST refer to the
base tracker protocol specification [I-D.ietf-ppsp-base-tracker-
protocol].
7. Security Considerations
The extended tracker protocol proposed in this document introduces no
new security considerations beyond those described in the base
tracker protocol specification [I-D.ietf-ppsp-base-tracker-protocol].
8. IANA Considerations
This draft introduces a new version number, see Table 1. Thus
corresponding IANA registration is required.
9. Acknowledgments
The authors would like to thank many people for their help and
comments, particularly: Zhang Yunfei, Martin Stiemerling, Fei Song,
Johan Pouwelse, and Arno Bakker.
The authors would also like to thank the people participating in the
EU FP7 project SARACEN (contract no. ICT-248474)
[refs.saracenwebpage] for contributions and feedback to this
document.
The views and conclusions contained herein are those of the authors
and should not be interpreted as necessarily representing the
official policies or endorsements, either expressed or implied, of
the SARACEN project or the European Commission.
10 References
10.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
[I-D.ietf-ppsp-base-tracker-protocol] Cruz, R., Nunes, M., Gu, Y.,
Xia, J., J. Taveira, and Lingli, D., "PPSP Tracker
Protocol-Base Protocol (PPSP-TP/1.0)", draft-ietf-ppsp-
Huang, et al. Expires September 10, 2015 [Page 15]
INTERNET DRAFT PPSP-TP/1.1 March 9, 2015
base-tracker-protocol-08 (work in progress), July 2014.
[I-D.ietf-ppsp-peer-protocol] Bakker, A., Petrocco, R. and V.
Grishchenko, "Peer-to-Peer Streaming Peer Protocol",
draft-ietf-ppsp-peer-protocol-12 (work in progress), June
2014.
10.2 Informative References
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008.
[refs.saracenwebpage] "SARACEN Project Website",
http://www.saracen-p2p.eu/.
[BFbitmap] Bloom, B., "Space/time trade-offs in hash coding with
allowable errors.", Communications of ACM Vol. 13, No.7,
pp. 422-426, 1970.
Authors' Addresses
Rachel Huang
Huawei
Phone: +86-25-56623633
EMail: rachel.huang@huawei.com
Rui Santos Cruz
IST/INESC-ID/INOV
Phone: +351.939060939
Email: rui.cruz@ieee.org
Mario Serafim Nunes
INESC-ID/INOV
Rua Alves Redol, n.9
1000-029 LISBOA, Portugal
Phone: +351.213100256
Email: mario.nunes@inov.pt
Joao P. Taveira
IST/INOV
Email: joao.silva@inov.pt
Lingli Deng
China Mobile
Email: denglingli@chinamobile.com
Huang, et al. Expires September 10, 2015 [Page 16]
