Tracker Protocol
draft-gu-ppsp-tracker-protocol-00

Abstract

This document defines P2P streaming Tracker Protocol, including functional entities and architecture, components, syntax and semantics.

This Tracker protocol is an application-level protocol for peers to register, publish/request content and provide peer status to Trackers. It is also for trackers to provide peer lists to peers, send control/manage messages and communicate with other trackers. Tracker protocol can serve live media and VoD applications, as well as file sharing.

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/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on September 2, 2010.

Copyright Notice

Copyright (c) 2010 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 BSD License.

Table of Contents

1.  Introduction
2.  Document Conventions
    2.1.  Notational Conventions
    2.2.  Terminology
3.  Protocol Overview
    3.1.  Function Entities and Interfaces
    3.2.  Use of Binary Messages
    3.3.  System Maintenance
    3.4.  Bootstrapping
    3.5.  NAT Traversal
4.  Protocol Parameters
    4.1.  Version
    4.2.  Swarm ID
    4.3.  Chunk ID
    4.4.  Peer ID
    4.5.  Message Length
5.  Method Definitions
    5.1.  Overlay Management Methods
    5.2.  Data Management Methods
    5.3.  Information Management Methods
    5.4.  Methods Representations
6.  Message Syntax
    6.1.  Message Header
    6.2.  Message Format
7.  Status Code Definitions
    7.1.  Success 0x1
    7.2.  Error
    7.3.  Server Error
8.  Security Consideration
9.  Acknowledgments
10.  References
    10.1.  Normative References
    10.2.  Informative References
§  Authors' Addresses

1.  Introduction

P2P Streaming Protocol includes two protocols, i.e. Tracker Protocol and Peer Protocol. Tracker Protocol provides communication between Trackers and Peers, by which Peers report streaming status to the tracker and request candidate lists from the tracker. [draft‑zhang‑ppsp‑problem‑statement] (Zhang, Y., Zong, N., Camarillo, V., Seng, J., and R. Yang, “Problem Statement of P2P Streaming Protocol (PPSP),” October 2009.) indicates that the Tracker protocol should standardize format/encoding of information between PPSP peers and PPSP trackers, as well as standardize messages between PPSP peers and PPSP trackers. [draft‑zong‑ppsp‑reqs] (Zong, N., Zhang, Y., Pascual, V., and C. Williams, “P2P Streaming Protocol (PPSP) Requirements,” October 2009.) list the detail requirements for Tracker Protocol.

This draft defines the Tracker Protocol. First of all, it analyzes the functional entities involved in Tracker protocol. Then, a list of functions is introduced. [draft‑zong‑ppsp‑reqs] (Zong, N., Zhang, Y., Pascual, V., and C. Williams, “P2P Streaming Protocol (PPSP) Requirements,” October 2009.) and [draft‑zhang‑ppsp‑problem‑statement] (Zhang, Y., Zong, N., Camarillo, V., Seng, J., and R. Yang, “Problem Statement of P2P Streaming Protocol (PPSP),” October 2009.) describe a basic set of functions and high-level requirements, however, this draft will introduce detailed and specific ones. The signaling/control path, corresponding to the functions are defined as well.

The principal part of the draft is syntax and semantics. These include parameters, methods, and message format. Most implemented P2P protocols are proprietary ones, as introduced in [draft‑gu‑ppsp‑survey] (Gu, Y., Zong, N., Zhang, H., Zhang, Y., Camarillo, G., and Y. Liu, “Survey of P2P Streaming Applications,” October 2009.). This draft intends to extract the fundamental features, functionalities and policies of the proprietary protocols and implementation experience, and present an early strawman sketch for an extensible protocol as a way to identify open isses and further discussion in the PPSP WG.

2.  Document Conventions

2.1.  Notational Conventions

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 [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

2.2.  Terminology

The draft uses the terms defined in [draft‑zhang‑ppsp‑problem‑statement] (Zhang, Y., Zong, N., Camarillo, V., Seng, J., and R. Yang, “Problem Statement of P2P Streaming Protocol (PPSP),” October 2009.).

This draft also uses some new terms. We list the relevant terms as following.

Swarm: A swarm is a set of peers who are sharing the same live channel or VoD.

Chunk: A chunk is a basic unit of partitioned stream, which is used by a peer for the purpose of storage, advertisement and exchange among peers.

Join Time: Join time is the absolute time when a peer registers on a Tracker. This value is recorded by the Tracker and is used to calculate Online Time.

Online Time: Online Time shows how long the peer has been in the P2P streaming system since it joins. This value indicates the stability of a peer, and it is calculated by Tracker when necessary.

Absolute Time: Absolute time is expressed as ISO 8601 [ISO.8601.2000] timestamps, using UTC (GMT). Fractions of a second may be indicated. Example for November 8, 1996 at 14h37 and 20 and a quarter seconds UTC:19961108T143720.25Z

STUN: Simple Traversal of UDP over NATs

TURN: Traversal Using Relay NAT

TLS: Transport Layer Security

3.  Protocol Overview

3.1.  Function Entities and Interfaces

First of all, we introduce the overview of Tracker Communication. A peer may get Tracker’s address by some way, e.g. from EPG, and then send JOIN message to the Tracker. Tracker receives the request, assigns a peer ID and response with the peer ID to the requesting peer. Meanwhile, Tracker updates the peer status records. The peer has to send KEEPALIVE message to notify Tracker about its existence periodically, or else Tracker will assume that the peer is offline and may remove the peer from content status and peer status. When the peer wants to watch a live channel or VoD, it sends a GET message to Tracker to show which content it is going to watch. Tracker replies with GET Response to provide candidate peers list, from which the peer can download content from. The peer can also PUT the content it owns to the Tracker and Tracker upon receiving PUT request will update content status to include the PUT peer into peer list. In order to obtain the latest condition of peers, Tracker may send STATISTICS messages to peers and peers report with the requested information. LEAVE message is sent from peer to Tracker to announce it is going to leave the system.

The entities and interfaces participating in the P2P streaming systems are in the figure bellow.

                     Application Layer
  ========================================================
                             Communication Layer
     Peer
          +-------------------+
          |peer signaling     |-------------------+
          |                   |Data management    |
          |                   | +===============+ |
          | +===============+ | |Swarm ID       | |
          | | JOIN/LEAVE/   | | | - Chunk ID    | |
          | | KEEPALIVE/PUT/| | |   - peer list | |
          | | GET           | | |   - Buffer map| |
          | +===============+ | +===============+ |
          +-------------------+                   |
                            +---------------------+
                         ^
      -------------------*----------------------------------------------
     Tracker             V
                +-------------------+
                |tracker signaling  |
                |                   |
                | (JOIN/LEAVE/      |
                |  KEEPALIVE/PUT/   |
                |  GET/STATISTICS)  |
                +-------------------+
           +----------------------------------------------------------+
           | Data management on Tracker                               |
           |                                                          |
           | +======================+       +======================+  |
           | |peer status           |       |content status        |  |
           | |  peer ID             |       |  +---------------+   |  |
           | |   - online time      |       |  | Swarm ID      |   |  |
           | |   - peer property    |       |  |  - Chunk ID   |   |  |
           | |   - link status      |       |  |    - peer list|   |  |
           | |   - etc.             |       |  +---------------+   |  |
           | +======================+       +======================+  |
           +----------------------------------------------------------+
      ==================================================================
                    Transport Layer
Fig 1 Function Entities of PPSP Tracker Communication

Interface between Tracker signaling and Peer Signaling entities support the following functions:

1)

Transmission of JOIN/LEAVE messages.

2)

Transmission of KEEPALIVE messages.

3)

Transmission of PUT messages, by which peers tell trackers what they have.

4)

Transmission of GET messages, by which peers request what they want and get candidate peers list from trackers.

5)

Transmission of STATISTICS requests and responses, by which trackers can get peers status, network performance, etc.

3.2.  Use of Binary Messages

We have two options to present the protocol, Binary Language and ASCII Language. Both have pros and cons. ASCII is easier for people to understand , but requires more space and bandwidth. Binary protocols are lighter in both bandwidth and processing, though are sometimes considered more difficult to understand.

Considering that peers communicate with extremely high frequency and the streaming application is much sensitive to delay, we choose Binary presentation when designing PPSP Tracker protocol in this draft.

Note: this is an open issue for WG to discuss and make determination. No matter which one is chosen, the basic design principle, including communication method and terminology, should be the same.

3.3.  System Maintenance

In order to keep the streaming system stable and efficient, trackers should periodically perform KEEPALIVE check to take into account peer failures. These KEEPALIVE messages are sent automatically by peers and trackers will verify that peers’ KEEPALIVE messages are recieved.

3.4.  Bootstrapping

When a peer wishes to join an existing P2P streaming application, it must first locate a Tracker in order to register and obtain a Peer ID. Peers may use any method to find a Tracker. Tracker discovery is out of scope of this specification.

3.5.  NAT Traversal

For simplicity, we assume that all trackers MUST be in public Internet and have been placed there deliberately. Since all sessions MUST be activated by Peers by sending Join messages, Tracker Communication will not encounter NAT issues. The issues of promotion, i.e. selecting peers be promoted as a tracker, or implementing a fully distributed tracker, will not be considered in this draft in this version.

4.  Protocol Parameters

4.1.  Version

Tracker protocol uses a "<major>.<minor>" numbering scheme to indicate versions of the protocol. The protocol versioning policy is intended to allow the sender to indicate the format of a message and its capability for understanding further communication, rather than the features obtained via that communication. No change is made to the version number for the addition of message components which do not affect communication behavior or which only add to extensible field values.

Version field is 8 bits. The first 4 bits represent <major> number and the rest 4 bits represent <minor> number.

The <minor> number is incremented when the changes made to the protocol add features which do not change the general message parsing algorithm, but which may add to the message semantics and imply additional capabilities of the sender. The <major> number is incremented when the format of a message within the protocol is changed.

Note that the major and minor numbers MUST be treated as separate integers and that each MAY be incremented by more than a single digit. Leading zeros MUST be ignored by recipients and MUST NOT be sent.

The current version is 0.0.

4.2.  Swarm ID

Swarm ID: Swarm ID is a 128 bits number to uniquely identify a swarm, as well as uniquely identify the particular program that the swarm is watching.

4.3.  Chunk ID

Chunk ID indicates the time period of a chunk in an on-demand-streaming. The Chunk ID of the first chunk of a content MAY be any number, however, it is RECOMMENDED to start at 0. For each sequential chunk, the Chunk ID MUST be incremented by one.

A swarm ID and a chunk ID uniquely identified a particular chunk in a particular streaming.

4.4.  Peer ID

Every peer owns a unique Identifier on a particular Tracker, i.e. Peer ID. Peer ID is a 128 bits number and is randomly generated when a peer registers.

4.5.  Message Length

Message Length (16 bit) indicates the length in Bytes of the message, including the message header and the following variable message body.

5.  Method Definitions

Methods represent the particular operations that peers/trackers want to do in PPSP Tracker Protocol. We have already listed some methods in the section 3. Here we introduce the specifications of these methods.

5.1.  Overlay Management Methods

Join: Join is the first method a peer performs. There is no relationship between peer and tracker before Join happens and no peer-ID is assigned as well. Tracker will never serve a peer who has not joined before. Peer registers in tracker by Join and tracker assigns in the response a peer-ID to peer, which is the only identification for peer in PPSP. Tracker records peer’s information, e.g. peer-ID, Join-time, peer property, peer link status, etc. After Join, peer owns the right to apply other methods on the tracker, e.g. to publish content availability on tracker or get peers lists from tracker for the specific content. JOIN is a mandatory method.

Leave: When peer intends to quit from the P2P streaming application, it sends Leave to the tracker. Tracker deletes the corresponding records related to the peer, including those in peer status and content status. After Leave, peer can not apply any methods except Join again, and will not reply to any request from trackers or other peers. Tracker will release the corresponding peer-ID. LEAVE is a mandatory method.

Keepalive: Keepalive message is periodically sent from peer to the tracker to notify that peer is still alive. If tracker does not receive keep-alive message for a configured time, it will assume that the peer is not available and do the same operations as in Leave. KEAPALIVE is an optional method.

Open issue: Should KEEPALIVE be used by peer to carry its current property if any change happens.

5.2.  Data Management Methods

Put: By Put, peer notifies tracker about which chunks of which swarms it owns. Tracker records the content availability in content status, i.e. adds peer to the candidate peers list for the notified chunk IDs of a particular swarm. PUT is a mandatory method.

Get: By Get, peer requests for lists of peers that can provide specific content from tracker. On receiving Get, tracker finds the candidate peers lists in content status. Tracker may take peer status and peers priority into consideration when it picks the candidate peers lists. Peers lists can be replied in more than more responses, in order to express tracker’s preference among candidate peers. By peer priority, we refer to the network topology preference or Operators’ policy preference, with regard to the possibility of connecting with other IETF efforts such as ALTO. In Live streaming, when receiving Get messages, tracker also updates content status to involve the new peer under a specific channel. GET is a mandatory method.

5.3.  Information Management Methods

Statistics: This method allows tracker to collect statistic data to improve system performance. STATISTICS is an optional method.

5.4.  Methods Representations

Method is an 8 bit field that indicates the message method. The first 2 bits show the communication type, i.e. tracker communication or peer communication.

Tracker-Communication : 0x0

Peer-Communication : 0x1 (Reserved)

Information-Statistics : 0x2

When the first 2 bits is 0x0, i.e. Tracker-Communication, the last 6bits represent the following different methods.

   JOIN          : 0x0
   LEAVE         : 0x1
   KEEPALIVE     : 0x2
   PUT           : 0x3
   GET           : 0x4

When the first 2 bits is 0x2, i.e. Information-Statistics, the last 6bits represent the following different methods.

STATISTICS : 0x1

6.  Message Syntax

This section provides the details of the binary encoding. Tracker protocol is a request-response protocol. The messages are encoded using binary fields. All integers are represented in network byte order and are present in base 10, decimal, unless otherwise noted in this draft.

Tracker protocol messages comprises of two parts: message header and message body.

Message header: contains some information for forwarding operations, for example, Protocol version, method and type. Tracker Protocol Message has a fixed length header. Fixed headers can be processed faster than messages without a fixed header because the headers can be processed by the stack and redirected to the appropriate peer without processing the entire message.

Message body: Message body is not designed to be some designated format, and it usually needs to be interpreted assisted by some fields in Message Header.

6.1.  Message Header

PPSP Protocol has a fixed length of messages header, including 4 bits Version, 1 bit R/r, 8 bits Method, 16 bits Message Length, 32 bits Transaction ID, 128 bits Source ID and 128 bits Destination ID.

 0               1               2               3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |Status |       |               | |             |
|   Version     |Code   | RSV   |    Method     |S|     RSV     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Message Length          |          Reserved             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      Fig 2 Message Header

The fields defined in Message Header is explained in corresponding section, shown in Table 1.

                  Table 1  Interpretation of Message Header
                  +---------------+--------------------+
                  | Header        | Defined in Section |
                  +---------------+--------------------+
                  | Version       | Section 4.1        |
                  |---------------|--------------------|
                  | Method        | Section 5.4        |
                  |---------------|--------------------|
                  | Message Length| Section 4.5        |
                  +---------------+--------------------+

6.1.1.  Status Code

Status Code : reflects a general status of the request.

The following status codes are examples. More detailed status codes interpretation are described in section 8.

Successful (OK)        : 0x1
Invalid syntax         : 0x2
Payment required       : 0x3
Request forbidden      : 0x4
Object not found       : 0X5
Internal server error  : 0X6
Does not support       : 0x7
Temporarily overloaded : 0x8
Version not support    : 0x9

6.1.2.  Series Flag

S Flag is ‘Series’ flag, which indicates whether this message is fragmented. If S is set, it means receiving end can expect more messages from the same sender. This flag is used from example, when the message body carries Peer List Info and Peer Property Info, which will be introduced in Section 7. For example S Flag is used in Get Message when there is a very long list of candidate peers sent from Tracker and the tracker would like to break it to a couple of messages.

If S is zero, it means the list in this message is either the whole list of peers or the last fragment of a message.

6.2.  Message Format

6.2.1.  JOIN

The JOIN procedure follows the general rules described below:

1)

A first message is sent, specifying the desire to join;

2)

A response including a chosen Peer ID and IP address/port from where the JOIN message comes, and Tracker will consider this pair of IP address/port as registration IP address/port of the joining peer.

JOIN REQUEST

0               1               2               3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |Status |       |               | |             |
|   Version     |Code   | RSV   |      JOIN     |S|     RSV     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Message Length          |C|                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Fig 3  Message Format of JOIN REQUEST

C is caching flag. If C is set, it means the joining peer has local caching and can provide uploading for other peers.(Open Question: Do we more detail about caching? What is cached? Question of rechability for peers providing cache support to other peers.)

JOIN RESPONSE

0               1               2               3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |Status |       |               | |             |
|   Version     |Code   | RSV   |      JOIN     |S|     RSV     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Message Length          |V|          RSV                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                            Peer ID (128bit)                   +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+             IPv4 Address(32bit)/ IPv6 address(128bit)        ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Port                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            Fig 4  Message Format of JOIN RESPONSE

V flag represents the version of IP address. If V flag is empty, it means the Address is IPv4 and the Address field is 32 bits, otherwise it’s IPv6 and the Address field is 128 bits.

6.2.2.  LEAVE

The LEAVE process MAY include the following steps:

1)

The leaving peer sends LEAVE request to Tracker.

2)

Tracker updates Peer Status and Content Status.

3)

Tracker responds leaving.

LEAVE REQUEST
0               1               2               3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |Status |       |               | |             |
|   Version     |Code   | RSV   |     LEAVE     |S|     RSV     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Message Length          |             RSV               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                           Peer ID(128bit)                     +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            Fig 5  Message Format of LEAVE REQUEST

LEAVE RESPONSE
0               1               2               3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |Status |       |               | |             |
|   Version     |Code   | RSV   |      LEAVE    |S|     RSV     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Message Length          |             RSV               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            Fig 6  Message Format of LEAVE RESPONSE

6.2.3.  KEEPALIVE

KEEPALIVE message is used by a peer to periodically notify Tracker that it is still alive. If Tracker has not received KEEPALIVE message from a particular peer, Tracker will regard the peer as offline and it will do the same as in LEAVE.

KEEPALIVE REQUEST
0               1               2               3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |Status |       |               | |             |
|   Version     |Code   | RSV   |     KEEPALIVE |S|     RSV     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Message Length          |C|           RSV               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                           Peer ID(128bit)                     +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Fig 7  Message Format of KEEPALIVE REQUEST

C flag represents the link status of the peer. If it is set, it means the peer is in congestion.

Open issue: the size of peer-ID, should we define it as fixed bits (how many bits are suitable) or make it extensible?

KEEPALIVE RESPONSE
0               1               2               3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |Status |       |               | |             |
|   Version     |Code   | RSV   |     KEEPALIVE |S|     RSV     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Message Length          |             RSV               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          Fig 8  Message Format of KEEPALIVE RESPONSE

6.2.4.  PUT

PUT message is used by a peer to publish what content it owns, or to notify its property.

Upon receiving PUT message, Tracker records the peer in content status and responds to the peer.

As we have mentioned in Section 6.1.3, PUT may carry different type of information in the Message Body. So in this section, we introduce the respective Message Format for different type of Message Body.

PUT-Resource Info REQUEST
0               1               2               3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |Status |       |               | | |           |
|   Version     |Code   | RSV   |     PUT       |S|C|   RSV     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Message Length          |K|E| U |  RSV  |  Chunk numbers|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Distance(optional)     |          RSV(optional)        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                           Peer ID(128bit)                     +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                       Swarm ID  (128bits)                     +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Chunk ID 1  (16bits, Optional) |                             . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . .                           |Chunk ID n  (16bits, Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Expiration Time(32 bits, Optional)               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       Fig 9  Message Format of PUT-Resource Info REQUEST

6.2.4.1.  PUT Resource Info

PUT-Resource Info REQUEST
0               1               2               3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               | |     | Status|               | | |           |
|   Version     |R|Pri. | Code  |     PUT       |S|C|   RSV     |
|               | |     |       |               | | |           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Message Length          |K|E| U |  RSV  |  Chunk numbers|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Distance(optional)     |          RSV(optional)        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                           Peer ID(128bit)                     +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                       Swarm ID  (128bits)                     +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Chunk ID 1  (16bits, Optional) |                             . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . .                           |Chunk ID n  (16bits, Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Expiration Time(32 bits, Optional)               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       Fig 10  Message Format of PUT-Resource Info REQUEST

C (1 bit): It represents which information is carried in message body, Resource Info or Peer Property Info. If it’s set, it means message body carries Resource Info, else it’s Peer Property Info.

K (1 bit): If this bit is set, Chunk ID field MUST be included; otherwise not.

E (1 bit): If this bit is set, Expiration Time field MUST be included; otherwise not.

Open issue:

U (1bit): When K is set, U should be interpreted. U represents how a peer PUT its resource. We have considered the following 3 ways to PUT resource.

U = 0x0 One Chunk ID in each PUT Resource message. This is appropriate when only one or few lately downloaded chunk need to be PUT. Chunk numbers is zero.

U = 0x1 Several Chunk IDs in one PUT Resource message. This is helpful to reduce volume of messages between peer and Tracker, especially when there is a large volume of chunk need to be PUT or when Chunks are not continuous. Chunk numbers indicates how many chunk IDs are included in the message body.

In the above two kind of scenario, the Distance field and the corresponding RSV field, which is designed for alignment, does not exist in the message and Tracker should not intend to interpret it.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Distance(optional)     |          RSV(optional)        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

However, unlike File sharing system, continuous Chunks are expected to be cached on peer in Streaming system. And, assuming that Tracker knows the distance between two continuous Chunk IDS and Chunk ID is evenly distributed, a peer can only include the First Chunk ID of a series of continuous Chunks and the number of Chunks to be PUT in PUT Resource message.

So we design the third way to PUT Resource.

U = 0x2 A PUT Resource message include First Chunk ID of a series of continuous Chunks, the number of Chunks to be PUT, and the distance of two continuous Chunk IDs. Chunk numbers indicates how many continuous Chunks, starting from the First Chunk ID, does the peer want to PUT.

In this scenario, the Distance field and the corresponding RSV field, which is designed for alignment, MUST be included and should be interpreted by Tracker. Distance indicates the difference between two continuous Chunk IDs, and is used by Tracker to calculate the Chunk ID that is not directly indicated in the message.

Open issue: How many bits should a Chunk ID occupy? One common method is to make the Chunk ID of a particular swarm starts from 0, and is increased by one for every next Chunk. However this is not always true. So how should we define the length of Chunk ID?

Chunk ID and Expiration Time is optional field. Here we give some examples whether these fields need to be set or not. In implementation, there might be other reasons for leaving out theses fields or not.

Chunk ID: If a peer is going to join a live channel, Chunk ID field is not necessary. If a peer is going to get a VoD chunk, it needs to indicate which chunk of the swarm it wants.

Expiration Time: If a peer is putting content on the tracker, it can decide whether to set an Expiration Time for the content.

Peer ID: Peer ID is the ID of the owner who owns the resource indicated by swarm ID and chunk ID.

If one optional field is not tagged, the corresponding value field will not be reserved.

PUT-Resource Info RESPONSE
0               1               2               3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |Status |       |               | |C|           |
|   Version     |Code   | RSV   |     PUT       |S|=|   RSV     |
|               |       |       |               | |1|           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Message Length          |             RSV               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       Fig 11  Message Format of PUT-Resource Info RESPONSE

If a peer PUT more than one Chunk a time and unfortunately fails, Tracker will notify the peer by PUT Resource Info response that PUT operation fails and all of the Chunks are not recorded correctly.

6.2.5.  PUT Peer Property Info

Peer Property Info is a TLV format. A PUT message can carry multiple peer property info in its message body.

The TLV format of Peer Property Info is as following:

0               1               2               3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |  P-Type       |           Reserved            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              Length                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Property Value                       . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             Fig 12  TLV Format of Peer Property

With this message, peer can notify Tracker of its property.

We define the following Type:

Table 2 Peer Property Type
+----------------------------------------------------------------+
|P-Type| Definition | Interpretation of Value field              |
+----------------------------------------------------------------+
| 0x00 |Caching size| available size of caching                  |
+----------------------------------------------------------------+
| 0x01 |Bandwidth   | available bandwidth                        |
+----------------------------------------------------------------+
| 0x02 |Link numbers| acceptable links for each remote peer      |
+----------------------------------------------------------------+
| 0x03 |Certificate | certificate of the peer                    |
+----------------------------------------------------------------+
| 0x04 |NAT/Firewall| peer behind NAT, Value field is empty      |
+----------------------------------------------------------------+
| 0x05 |STUN        | peer supports STUN service,                |
|      |            | Property Value is empty                    |
+----------------------------------------------------------------+
| 0x06 |TURN        | peer supports TURN service,                |
|      |            | Property Value is empty                    |
+----------------------------------------------------------------+
| 0x07 |Sum Volume  | Sum of bytes of data peers receives        |
|      |            | from the steaming system                   |
+----------------------------------------------------------------+
| 0x08 |Access Mode | ADSL/Fiber/GPRS/3G/LTE/WiFi                |
+----------------------------------------------------------------+
| 0x09 |End Device  | STB/PC/MobilePhone                         |
+----------------------------------------------------------------+
| 0x0a |Available   |                                            |
|      |Battery     |                                            |
|      | Volume     |                                            |
+----------------------------------------------------------------+

0x09 End Device is especially meaningful for Mobile phone users, by which they can choose a peer with the same end Device in order to avoid transcoding, or choose a PC peer which may have higher download bandwidth and larger caching size than Mobile phone.

0x0a Available Battery Volume implies the stability of a peer. If there is large percent of battery left on a mobile peer, it may support service longer than one with less battery.

Property Length represents the length in Bytes of the Property Value field.

If there is a large volume of property values to carry, the message can be fragmented to a series of messages. The S Flag in Message Header should be set. We suggest each fragment should carry one or more complete value, to put it another way, do not split a value into different fragments.

PUT-Peer Property Info request
0               1               2               3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |Status |       |               | |C|           |
|   Version     |Code   | RSV   |     PUT       |S|=|    RSV    |
|               |       |       |               | |0|           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Message Length          |              RSV              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                           Peer ID(128bit)                     +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                           TLV Element                         +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                           . . .                               +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                           TLV Element                         +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    Fig 13  Message format of PUT-Peer Property Info REQUEST

PUT-Resource Info response
0               1               2               3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |Status |       |               | |C|           |
|   Version     |Code   | RSV   |     PUT       |S|=|   RSV     |
|               |       |       |               | |0|           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Message Length          |             RSV               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    Fig 14  Message format of PUT-Peer Property Info RESPONSE

6.2.6.  GET

GET message is used by a requesting peer to request Tracker for list of candidate peers that can provide particular content.

Upon receiving GET message, Tracker will do the following steps:

1)

Tracker searches Content Status to find out peers list that can provide the content indicated in the Resource Info.

2)

According to the candidate peers property recorded in Peer Status, Tracker pick out the appropriate candidate peers than can satisfy the Destination Peer Preference Info, if applicable.

3)

Tracker sends to requesting peer the appropriate candidate peers list, to which requesting peer can ask for wanted content.

4)

Meanwhile, Tracker updates the content status and peer status to reflect the latest status.

If there is no candidate peer for the wanted content, Peer List Info will not be presented.

A better way to improve general system preference is to provide candidate peer list with peers who have similar host property to the requesting peer. So that a Destination Peer Preference is introduced in GET to enable requesting peer to notify Tracker which property of a destination peer it prefers.

6.2.6.1.  GET Peer List Info without Destination Peer Preference

GET REQUEST without Destination Peer Preference
0               1               2               3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |Status |       |               | |D|           |
|   Version     |Code   | RSV   |     GET       |S|=|   RSV     |
|               |       |       |               | |0|           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Message Length          |K|            RSV              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                           Peer ID(128bit)                     +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                       Swarm ID  (128bits)                     +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Chunk ID  (128bits, Optional)                    +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig 15  Message format of GET REQUEST without Destination Peer Preference

K (1 bit): If this bit is set, Chunk ID field MUST be included; otherwise not.

D (1 bit): This flag implies whether requesting peer wants to GET peer list with Destination property preference. If it’s empty, it means requesting peer has no preference. If it’s set, it means requesting peer has indicated Destination property preference in message body.

GET response

Open issues: Which information should be carried as Peer List, Peer Address or Peer ID? This issue has close relationship with Peer Protocol, because it will influence the way that peers communicate when they are behind NAT.

1)

If Peer Address, e.g. IPv4/IPv6 address, is carried, then requesting peer can communicate with the candidate peers after obtaining Peer List Info, if the candidate peer is in public network or is behind Full Cone NAT. One possible problem is that candidate peers might be behind more restrictive NAT, e.g. Address-Restricted, Port-Restricted and symmetric NAT, which makes direct communication between peers difficult.

2)

If Peer ID is carried, we have to consider at least two scenario. One is a Tracker-based P2P network without structured topology among peers, e.g. topology organized by Chord. In this network, peers totally depend on Tracker to search content and locate peers. So even requesting peer obtains candidate Peer ID, it has to ask Tracker to translate Peer ID into IP address before it can communicate with candidate peers, which means providing Peer ID in this scenario is helpless. Another is a Tracker-based P2P network with structured topology among peers. In this case, if Peer ID is provided in Peer List, requesting peer can find and establish connection with the candidate peers by mechanism like RELOAD. NAT Traversal problem still exists if Peer ID is carried. And peers cannot directly communicate even if they are in public network.

It’s too early to decide which one is more appropriate when we define Tracker Protocol. We may have to wait and make progress inline with Peer Protocol. Herein, we leave it as an open issue and temporarily define a structure that can be interpreted as either Peer IP Address or Peer ID, and we call it Peer Identity.

Note that, because of the limited packet size, message with a very long list of peers will be split into several packets and the S Flag in Message Header will be set. The requesting peer has to wait until all packets are received before it is able to get the whole peer list. An improved solution is for Tracker to split the peer list into several lists of peers and responds in series, according to some ISP preference, such as peer preference defined by ALTO, and preferred peers status defined in Destination Peer Preference Info. Then requesting peer needs not to wait for the whole list of candidate peers and the peers it has already received are much likely to serve it better than those come later.

Peer Identity, which could be IP Address or Peer ID, has the following structure.

0               1               2               3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P|V|                           |                Port           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Identity (IPv4 Address:32bits/IPv6 Address or Peer ID:128bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             Fig 16  Message format of Peer Identity

P indicates what is carried in Peer Identity, 0 for Peer IP Address and 1 for Peer ID. If P=0, V flag and port field is interpreted.

V represents IP version. If V is empty, the IP Address is IPv4 and last 32bits of the 128bits Identity field is interpreted. If V is set, the IP Address is IPv6.

If P=1, neither V nor Port is interpreted.

The integrated message of GET response is as following.

0               1               2               3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |Status |       |               | |D|           |
|   Version     |Code   | RSV   |      GET      |S|=|           |
|               |       |       |               | |0|           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Message Length          |          Reserved             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Peer Identity 1                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   ............                                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Peer Identity N                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Expiration Time                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             Fig 17  Message format of GET RESPONSE

Expiration Time is defined here to indicate how long the response could live, out of security consideration. It is Absolute time. The information provided in this message should not be used or distributed by peers after Expiration Time. Some P2P streaming application allows peers to share local peer list, and we are still not sure whether this will be permitted in PPSP Peer Protocol. One big problem of sharing peer list is validity. For example, a peer, who is recorded in the peer list, may delete the content but is still in peer list of the content.

6.2.6.2.  GET Peer List with Destination Peer Preference Info

Requesting peer can include Destination Peer Preference Info in the message to indicate what kind of property the Destination Peer should have. With Destination Peer Property Info message, a peer can notify Tracker which kind of destination peer it prefers. This message does not list the detail value of each kind of property, instead peer’s preference is expressed by several tags.

0               1               2               3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |Status |       |               | |D|           |
|   Version     |Code   | RSV   |     GET       |S|=|   RSV     |
|               |       |       |               | |1|           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Message Length          |K|S|T|L|N|         RSV         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                           Peer ID(128bit)                     +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                       Swarm ID  (128bits)                     +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+              Chunk ID  (128bits, Optional)                    +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|B|L|N|Y|T|             Property Type                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Expiration Time                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig 18  Message format of GET REQUEST with Destination Peer Preference Info

K (1 bit): If this bit is set, Chunk ID field MUST be included; otherwise not.

If Y flag is set, it means the requesting peer want to download from destination peer with high security levels, e.g a peer supports signature mechanism is preferred.

If T flag is set, it means the requesting peer want to download from destination peer who has stay in the system for a relatively long time.

If L flag is set, it means the requesting peer want to download from destination peer with large number of concurrent links.

If N flag is set, it means the requesting peer do not mind downloading from destination peer behind NAT. If it’s empty, it means the requesting peer do not accept destination peer behind NAT

Tracker will interpret and choose appropriate candidate peers according to Destination Peer Property. The response is the same as that of GET response described in section6.2.5.1.

6.2.7.  STATISTICS

By Statistics message, Tracker can ask peer to report peer property info. Besides Tracker can also request for what contents a peer owns and the sum of bytes of data it receives from the streaming system.

STATISTICS request
0               1               2               3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               | |     | Status|               | |             |
|   Version     |R|Pri. | Code  | STATISTICS    |S|     RSV     |
|               | |     |       |               | |             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Message Length          |    p-Type     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       Fig 19  Message format of STATISTICS REQUEST

p-Type(8bits) indicates which attributes the Tracker want to know. STATISTICS reuses the p-Type defined in section 6.2.4.2, though not all the p-Types defined in 6.2.4.2 will be applicable in STATISTICS. For example, Caching size(0x00), Bandwidth(0x01), Link numbers(0x02) and Sum Volume(0x07)is introduced. Besides, two new types are defined herein.

Table 3 Statistics Attributes
+---------------------+
|P-Type| Definition   |
+---------------------+
| 0x00 |Caching size  |
+---------------------+
| 0x01 |Bandwidth     |
+---------------------+
| 0x02 |Link numbers  |
+---------------------+
| 0x07 |Sum Volume    |
+---------------------+
| 0x08 |Content report|
+---------------------+

STATISTICS response resembles the PUT-Peer Property Info request, e.g. using TLV format to present peer property and can be split into several messages of response.

0               1               2               3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               | |     | Status|               | |             |
|   Version     |r|Pri. | Code  |  STATISTICS   |S|     RSV     |
|               | |     |       |               | |             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Message Length          |              RSV              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                           Peer ID(128bit)                     +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                           TLV Element                         +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                           . . .                               +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                           TLV Element                         +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          Fig 20  Message format of STATISTICS RESPONSE

Particularly, when p-Type is 0x08, PUT request is used to respond to STATISTICS request, and PUT response is sent back from Tracker as normal PUT request and response.

7.  Status Code Definitions

7.1.  Success 0x1

The request has succeeded. The information returned with the response is dependent on the method used in the request.

7.2.  Error

This class of status code indicates that the peer’s request was not successfully received, understood, nor accepted.

7.2.1.  Invalid syntax 0x2

The request could not be understood by the Tracker due to malformed syntax. The peer SHOULD NOT repeat the request without modifications.

7.2.2.  Invalid syntax 0x2

The request could not be understood by the Tracker due to malformed syntax. The peer SHOULD NOT repeat the request without modifications.

7.2.3.  Payment required 0x3

The request lack necessary information.

7.2.4.  Request forbidden 0X4

The requesting peer is forbidden to send such request. For example, peer can not sent GET request before JOIN.

7.2.5.  Object not found 0X5

The target resource is not recorded on Tracker.

7.3.  Server Error

This class of status code indicates that the in-network storage does not work correctly.

7.3.1.  Internal server error 0X6

Tracker has internal error and could not work correctly to the request. The peer could try the same request later.

7.3.2.  Does not support 0x7

Tracker does not support the functionality required to fulfill the request. The peer should not send the request again. For example, Tracker is running an old version of Tracker Protocol and could not understand some requests from a peer with latest version.

7.3.3.  Temporarily overloaded 0x8

Tracker is overloaded. The peer should try the request later.

7.3.4.  Version not support 0x9

Tracker does not support the version in the request.

8.  Security Consideration

We consider that at least 3 security aspects should be studied in Tracker Protocol.

1)

To avoid wire tapping between Tracker and peer. This is about peer privacy. Maybe TLS can be used to protect peer privacy.

2)

To avoid over distributing of Peer list, which can be solved by Expiration Time in GET response.

3)

Tracker Identity verification. Signature of Tracker can be adopted to certify that the particular message is from the right Tracker. Peer can get Public key of Tracker from Tracker or from a third party. Tracker responses with signature and then peers can affirm that the Identity of the sender.

Security will be considered in further version of this draft.

9.  Acknowledgments

We give our acknowledgements to the following persons for their help and comments: Roni Even, Bhumip Khasnabish,Wu Yichuan, Peng Jin, Chi Jing, Zong Ning, Song Haibin, Zhijia Chen, Schmidt Christian, Kangheng Wu.

10.  References

10.1. Normative References

10.2. Informative References

Authors' Addresses