GIST: General Internet Signalling Transport

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF.

Title : GIST: General Internet Signalling Transport
Author(s) : H. Schulzrinne, M. Stiemerling
Filename : draft-ietf-nsis-ntlp-20.txt
Pages : 156
Date : 2009-06-03

This document specifies protocol stacks for the routing and transport of per-flow signalling messages along the path taken by that flow through the network. The design uses existing transport and security protocols under a common messaging layer, the General Internet Signalling Transport (GIST), which provides a common service for diverse signalling applications. GIST does not handle signalling application state itself, but manages its own internal state and the configuration of the underlying transport and security protocols to enable the transfer of messages in both directions along the flow path. The combination of GIST and the lower layer transport and security protocols provides a solution for the base protocol component of the "Next Steps in Signalling" framework.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-20.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Problem Statement of P2P Streaming Protocol (PPSP)

"We propose to develop an open peer-to-peer (P2P) streaming protocol named PPSP. This document describes the problems related to PPSP and outlines considerations that have to be taken in account when arriving at equitable solutions." ... this is the abstract but what's the actual scope of the problem statement?

• Proprietary protocols and an open PPSP
• Integrating cache and CDN into P2P streaming
• Integrating existing protocols into P2P streaming
• Mobility and wireless issue such as end to end communication is harder and limited bandwidth resource

The design issues include the choice of architecture and integration with existing protocols (i.e., legacy issues) such as RELOAD, ALTO, RTSP (and encapsulation), and edge devices (e.g., cache integration).

Application-Layer Traffic Optimization (ALTO) Problem Statement

Peer-to-peer applications, such as file sharing, real-time communication, and live media streaming, use a significant amount of Internet resources. Such applications often transfer large amounts of data in direct peer-to-peer connections. However, they usually have little knowledge of the underlying network topology. As a result, they may choose their peers based on measurements and statistics that, in many situations, may lead to suboptimal choices. This document describes problems related to optimizing traffic generated by peer-to-peer applications and associated issues such optimizations raise in the use of network-layer information.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-alto-problem-statement-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

P2P Streaming Protocols at IETF v2

I recently blogged about P2P Streaming Protocols at IETF. Now the slides of this bar BoF meeting are available here. The minutes one can find on the list archives for those who are not subscribed. It is difficult to draw real conclusions at this point in time as much things are not yet clear enough. From the meeting minutes one can extract "still have uncertainties of the goal of PPSP", "PPSP should "narrow" its scope", and "proceed with a proper BOF at the next IETF". Thus, it is suggested to work "on an architecture document covering different components and analyze each components wrt to the work done or current being work upon by other WG in IETF".

P2P Streaming Protocols at IETF

It seems that the IETF is starting to form a P2P Streaming Protocols activity as there will be a BoF meeting during 74th IETF in San Francisco in March 2009. The agenda covers the following items:

• Problem Statement
• Protocol Requirements
• Protocol Analysis of PPlive and PPStream by Interent Measurement
  
• Introduction of Distributed Services Network, a vision of making PPSP and P2PSIP into reality

Furthermore, it seems that China Mobile and Huawei Technologies are the driving forces behind this exciting activity. There's also an email reflector to which one can subscribe here. I've just subscribed an I'm eager to learn more about what's going on there...

P2P News from IETF

As some people know the IETF is taking some actions w.r.t. the standardization of protocols related to Peer-to-Peer (P2P) technology within ALTO and P2PSIP groups. Recently, two new drafts have been submitted which might be interesting to some of you:

The first one is entitled An Architecture of ALTO for P2P Applications with the following abstract: ALTO enables Internet Service Providers (ISPs) and network application software distributors to work jointly and cooperatively to reduce network resource consumption and to improve application performance. In this document, we specify an architecture for integrating ALTO into peer-to-peer (P2P) applications.

The second one is related to P4P Protocol Specification: Provider Portal for Network Applications (P4P) is a framework that enables Internet Service Providers (ISPs) and network application software developers to work jointly and cooperatively to optimize application communications. The goals of this cooperation are to reduce network resource consumption and to accelerate applications. To achieve these goals, P4P allows ISPs to provide network information and guidance to network applications, allowing clients to exchange data more effectively. This document specifies the P4P protocol operations and message formats. The goal is provide a formal specification for developers to create inter-operable implementations.

Please note that latter is mainly driven by Yale University and is in competition with the so-called Oracle Service developed by an institute of the Deutsche Telekom Laboratories, namely the research group of Anja Feldmann. I wonder whether they will start/join the "standardization war".

How to Write an RTP Payload Format

draft-ietf-avt-rtp-howto-06

Abstract: This document contains information on how to best write an RTP payload format. Reading tips, design practices, and practical tips on how to quickly and with good results produce an RTP payload format specification. A template is also included with instructions that can be used when writing an RTP payload format.

If you're looking forward to write an RTP payload format, I guess this document may be helpful unless you're an IETF RTP playload format guru ;-) If you're not sure, here's the definition of an RTP playload format:

"The RTP Payload format specifies how a specific media format is put into the RTP Payloads. Thus enabling the format to be used in RTP sessions."

Overall, a useful document and check out the references section for a list of existing payload formats.

Peer-to-peer (P2P) Architectures

Peer-to-peer (P2P) Architectures, draft-iab-p2p-archs-00.txt

Abstract (copy/paste from the draft):

In this document we provide a survey of P2P (Peer-to-Peer) systems. The survey includes a definition and a taxonomy of P2P systems. This survey also includes a description of which types of applications can be built with P2P technologies and examples of P2P applications that are currently in use on the Internet. Finally, we discuss architectural tradeoffs and provide guidelines for deciding whether or not a P2P architecture would be suitable to meet the requirements of a given application.

Very interesting survey with a lot of useful pointers, among them I'd like to mention Peltotalo, J., Harju, J., Jantunen, A., Saukko, M., and L. Vaeaetaemoeinen, "Peer-to-Peer Streaming Technology Survey", Seventh International Conference on Networking, Cancun, Mexico, pp. 342-350 , April 2008. At the end one can find a summary of existing peer-to-peer streaming technologies.

The P2P architectures' draft also provides a definition of a P2P system. However, this definition encompasses mainly that

"peers share their processing and storage capacity (i.e., their hardware and software resources) so that the system can provide a service"

In my view this is too weak and I'd like to provide a quote which I've reported some time ago that defines a P2P system as follows:

"(1) peers act as client and server, (2) they provide computational/storage resources to other peers, and (3) they're self-organizing and scaling."

The third property is the most important one as (1) and (2) is also true for several proxies out there...

Quality of Service (QoS) Mechanism Selection in SDP

The IESG (note: part of IETF) has approved a draft which enables negotiating which QoS mechanism to use for a particular media stream: end-to-end with a differentiation between upstream and downstream. Therefore, two new attributes have been defined: qos-mech-send and qos-mech-recv. However, currently only two QoS mechanisms are defined, namely nsis and rsvp. Other mechansims - existing or future ones - needs to be registerd through IANA. The following example describes a session which support RSVP and NSIS in both directions whith a preference on RSVP. That is, the order of the actual QoS mechanisms is important.

   m=audio 55000 RTP/AVP 0
   a=qos-mech-send: rsvp nsis
   a=qos-mech-recv: rsvp nsis

The current draft can be found here.