[ppsp] Fwd: New Version Notification for draft-ietf-ppsp-peer-protocol-04.txt

Arno Bakker <arno@cs.vu.nl> Thu, 06 December 2012 13:07 UTC

Return-Path: <a.bakker@vu.nl>
X-Original-To: ppsp@ietfa.amsl.com
Delivered-To: ppsp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8F9F21F8646 for <ppsp@ietfa.amsl.com>; Thu, 6 Dec 2012 05:07:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.039
X-Spam-Level:
X-Spam-Status: No, score=-4.039 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0y1CDBeOMAvw for <ppsp@ietfa.amsl.com>; Thu, 6 Dec 2012 05:07:45 -0800 (PST)
Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8476B21F860D for <ppsp@ietf.org>; Thu, 6 Dec 2012 05:07:38 -0800 (PST)
Received: from PEXHB011A.vu.local (130.37.236.64) by mailin.vu.nl (130.37.164.17) with Microsoft SMTP Server (TLS) id 14.2.298.4; Thu, 6 Dec 2012 14:07:37 +0100
Received: from [130.161.211.249] (130.37.238.20) by mails.vu.nl (130.37.236.64) with Microsoft SMTP Server (TLS) id 14.2.298.4; Thu, 6 Dec 2012 14:07:37 +0100
Message-ID: <50C098C4.4050209@cs.vu.nl>
Date: Thu, 06 Dec 2012 14:08:20 +0100
From: Arno Bakker <arno@cs.vu.nl>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: ppsp <ppsp@ietf.org>
References: <20121206130128.24588.41314.idtracker@ietfa.amsl.com>
In-Reply-To: <20121206130128.24588.41314.idtracker@ietfa.amsl.com>
X-Forwarded-Message-Id: <20121206130128.24588.41314.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [130.37.238.20]
Subject: [ppsp] Fwd: New Version Notification for draft-ietf-ppsp-peer-protocol-04.txt
X-BeenThere: ppsp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: arno@cs.vu.nl
List-Id: discussing to draw up peer to peer streaming protocol <ppsp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ppsp>, <mailto:ppsp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ppsp>
List-Post: <mailto:ppsp@ietf.org>
List-Help: <mailto:ppsp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ppsp>, <mailto:ppsp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Dec 2012 13:07:46 -0000

Hi

I updated the peer protocol draft, see revision history below.

CU,
     Arno

==============
    -04	2012-11-07 Minor revision

        *   Corrected typos.

        *   Added empty protocol option list when HANDSHAKE is used for
            explicitly closing a channel in the UDP encapsulation.

        *   Corrected definition of a range chunk specification to be a
            single (start,end) pair.  To send multiple disjunct ranges
            multiple messages should be used.

        *   Clarified that in a range chunk specification the end is
            inclusive.  I.e., [start,end] not [start,end)

        *   Added PEX_REScert message to carry a membership certificate.
            Renamed PEX_RES to PEX_RESv4.

        *   Added a guideline about private and link-local addresses in
            PEX_RES messages.

        *   Defined the format of the public key that is used as swarm ID
            in live streaming.

        *   Clarified that a HANDSHAKE message must be the first message
            in a datagram.

        *   Clarified sending INTEGRITY messages ahead in a separate
            datagram if not all necessary hashes that still need to be
            sent and the chunk fit into a single datagram.  Defined an
            order for the INTEGRITY messages.

        *   Clarified rare case of sending multiple DATA messages in one
            datagram.

        *   Clarified UDP datagrams carrying PPSPP should adhere to the
            network's MTU to avoid IP fragmentation.

        *   Defined value for version protocol option.

        *   Added small clarifications and corrected typos.

        *   Extended versioning scheme to Min/max versioning scheme
            defined in [RFC6709], Section 4.1, following Riccardo
            Bernardini's suggestion.

        *   Processed comments on unclear phrasing from Riccardo
            Bernardini.

        *   Added a guideline on when to declare a peer dead.

        *   Made sure all essential references are listed as Normative
            references following RFC3967.



-------- Original Message --------
Subject: New Version Notification for draft-ietf-ppsp-peer-protocol-04.txt
Date: Thu, 6 Dec 2012 05:01:28 -0800
From: <internet-drafts@ietf.org>
To: <arno@cs.vu.nl>
CC: <r.petrocco@gmail.com>, <victor.grishchenko@gmail.com>


A new version of I-D, draft-ietf-ppsp-peer-protocol-04.txt
has been successfully submitted by Arno Bakker and posted to the
IETF repository.

Filename:	 draft-ietf-ppsp-peer-protocol
Revision:	 04
Title:		 Peer-to-Peer Streaming Peer Protocol (PPSPP)
Creation date:	 2012-12-06
WG ID:		 ppsp
Number of pages: 57
URL: 
http://www.ietf.org/internet-drafts/draft-ietf-ppsp-peer-protocol-04.txt
Status: 
http://datatracker.ietf.org/doc/draft-ietf-ppsp-peer-protocol
Htmlized:        http://tools.ietf.org/html/draft-ietf-ppsp-peer-protocol-04
Diff: 
http://www.ietf.org/rfcdiff?url2=draft-ietf-ppsp-peer-protocol-04

Abstract:
    The Peer-to-Peer Streaming Peer Protocol (PPSPP) is a transport
    protocol for disseminating the same content to a group of interested
    parties in a streaming fashion.  PPSPP supports streaming of both
    pre-recorded (on-demand) and live audio/video content.  It is based
    on the peer-to-peer paradigm, where clients consuming the content are
    put on equal footing with the servers initially providing the
    content, to create a system where everyone can potentially provide
    upload bandwidth.  It has been designed to provide short time-till-
    playback for the end user, and to prevent disruption of the streams
    by malicious peers.  PPSPP has also been designed to be flexible and
    extensible.  It can use different mechanisms to optimize peer
    uploading, prevent freeriding, and work with different peer discovery
    schemes (centralized trackers or Distributed Hash Tables).  It
    supports multiple methods for content integrity protection and chunk
    addressing.  Designed as a generic protocol that can run on top of
    various transport protocols, it currently runs on top of UDP using
    LEDBAT for congestion control.

 



The IETF Secretariat