From a.bakker@vu.nl Wed May 1 06:56:56 2013 Return-Path: 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 0F37221F9822 for ; Wed, 1 May 2013 06:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.504 X-Spam-Level: X-Spam-Status: No, score=-4.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrNr78nKyL7m for ; Wed, 1 May 2013 06:56:49 -0700 (PDT) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.17]) by ietfa.amsl.com (Postfix) with ESMTP id 555A721F94FF for ; Wed, 1 May 2013 06:56:48 -0700 (PDT) Received: from PEXHB012B.vu.local (130.37.236.67) by mailin.vu.nl (130.37.164.17) with Microsoft SMTP Server (TLS) id 14.2.298.4; Wed, 1 May 2013 15:56:47 +0200 Received: from [192.168.0.100] (130.37.238.20) by mails.vu.nl (130.37.236.67) with Microsoft SMTP Server (TLS) id 14.2.298.4; Wed, 1 May 2013 15:56:47 +0200 Message-ID: <51811F77.3070903@cs.vu.nl> Date: Wed, 1 May 2013 15:58:15 +0200 From: Arno Bakker User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: References: <517F8C7B.20106@neclab.eu> In-Reply-To: <517F8C7B.20106@neclab.eu> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [130.37.238.20] Subject: Re: [ppsp] AD review of draft-ietf-ppsp-peer-protocol-06 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 13:56:56 -0000 Hi Martin thanks for the in-depth review. The authors will go over them in detail, but two remarks need to be made now. Please see inline. On 30/04/2013 11:18, Martin Stiemerling wrote: > > Please find here the review of your Area Director for > draft-ietf-ppsp-peer-protocol-06. This includes all sections except 12 > and 13. > The draft cannot be fully understood without reading Section 13 about the Security Considerations. This will resolve some of the points you made (channel IDs, PEX_REScert). We welcome recommendations on items from that section that should be moved forward in the document. Of course, we will look at them ourselves. > ***High-level issues: > 1) Merkle Hash Trees > I have found the document very confusing on whether Merkle Hash Trees > (MHTs) and the for the MHT required bin numbering scheme are now > optional or mandatory. Parts of the draft make the impression that > either of them or both or optional (mainly in the beginning of the > document), while Section 5 and later Sections are relying heavily on MHTs. > MHTs are mandatory to implement for static content. I.e., all implementations should at least support this mechanism. It is not required to be used for all swarms. This is to ensure there is at least one secure configuration of the protocol that all implementations speak (an IETF goal AFAIK). So mandatory to implement, optional to use. We'll make sure this is clearer. > My naive reading of the current draft is that you could rely on > start-end ranges for chunk addressing and MHTs for content protection. > However, I do know that this combination is not working. > Section 5, last paragraph clearly states: "The Merkle hash tree scheme can use different chunk addressing schemes. All it requires is the ability to address a range of chunks." Hence, MHTs work with all numbering schemes defined in the spec. What makes you think it doesn't work with start-end ranges? The compliant implementation is working fine with this scheme. Regards, Arno From a.bakker@vu.nl Wed May 8 02:47:54 2013 Return-Path: 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 4CEEC21F9054 for ; Wed, 8 May 2013 02:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.504 X-Spam-Level: X-Spam-Status: No, score=-3.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPaNvShMOKvo for ; Wed, 8 May 2013 02:47:48 -0700 (PDT) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2A121F905F for ; Wed, 8 May 2013 02:47:43 -0700 (PDT) Received: from PEXHB012B.vu.local (130.37.236.67) by mailin.vu.nl (130.37.164.18) with Microsoft SMTP Server (TLS) id 14.2.298.4; Wed, 8 May 2013 11:47:44 +0200 Received: from [192.168.0.100] (130.37.238.20) by mails.vu.nl (130.37.236.67) with Microsoft SMTP Server (TLS) id 14.2.298.4; Wed, 8 May 2013 11:47:41 +0200 Message-ID: <518A1F9D.5010606@cs.vu.nl> Date: Wed, 8 May 2013 11:49:17 +0200 From: Arno Bakker User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Martin Stiemerling , ppsp References: <517F8C7B.20106@neclab.eu> In-Reply-To: <517F8C7B.20106@neclab.eu> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [130.37.238.20] Subject: Re: [ppsp] AD review of draft-ietf-ppsp-peer-protocol-06 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 09:47:54 -0000 Hi Martin we agreed with the document sheperd, Stefano, that we would request clarification of issues directly from you, instead of via him. So can you please clarify your comments, as indicated below? Once all issues are clarified we will address each of them in a subsequent mail. On 30/04/2013 11:18, Martin Stiemerling wrote: > > ***High-level issues: > 1) Merkle Hash Trees > I have found the document very confusing on whether Merkle Hash Trees > (MHTs) and the for the MHT required bin numbering scheme are now > optional or mandatory. Parts of the draft make the impression that > either of them or both or optional (mainly in the beginning of the > document), while Section 5 and later Sections are relying heavily on > MHTs. > > My naive reading of the current draft is that you could rely on > start-end ranges for chunk addressing and MHTs for content protection. > However, I do know that this combination is not working. > Can you clarify why this combination does not work in your view? > If MHTs are really optional, including the bin numbering, the document > should really state this and make clear what the operations of the > protocol are with the mandatory to implement (MTI) mechanisms. The > MHT, bins, and all the protocol handling should go in an appendix. Questions from our side: * Given MHTs are intended to be mandatory-to-implement, is the current presentation in the main body of the text OK? * Given start-end ranges of chunks are intended to be mandatory-to-implement, do you want other optional chunk addressing schemes, such as bins, to be moved to appendices? * Do you have a reference to the syntax for specifying MTI. Or is that just the phrase "mandatory to implement" and MUST clauses? > 3) No formal protocol message definition > Section 7 and more specific Section 8 describe the protocol syntax of > the protocol options and the messages, though Section 8 is talking > about UDP encapsulation. > Section 7 is hard to digest if someone should implement the options, > see also later, but Section 8 is almost impossible to understand by > somebody who has not been involved in the PPSP working group. See > also further down for a more detailed review of the sections. Do you mean the draft should have a ABNF specification of the protocol? > 4) Implicit use of default values > There are a number of places all over the draft where default values > are defined. Many of those default values are used when there are no > values explicitly signaled, e.g., the default chunk size of 1 Kbyte > in Section 8.4 or Section Section 7.5. with the default for the > Content Integrity Protection Method. > I have the feeling that the protocol and the surroundings (e.g., what > comes in via the 'tracker') are over-optimized, e.g., always providing > the Content Integrity Protection Method as part of the Protocol > options will not waste more than 2 bytes in a HANDSHAKE message. > Further, I do not see the need to define a default chunk size in the > base protocol specification, as this default can look very different, > depending on who is deploying the protocol and in what context. This > calls for a more dynamic way of handling the system chunk size, either > as part of an external mechanisms (e.g. via the tracker) or in the > HANDSHAKE message. > RFC5706 "Guidelines for [...] Operations and Management" calls for "a sensible default value for all parameters." Do you want us: i) to rephrase the 1K default chunk size as sensible default (so a suggestion instead of a standard-setting value) ii) just explain considerations for choosing this value, without an explicit default? > 5) Concept of channels > The concept of channels is good but it is introduced too late in the > draft, namely in Section 8.3, and it is introduced with very few > words. Why isn't this introduced as part of Section 2 or Section 3, > also in the relationship to the used transport protocol? In our design channels only exist in the UDP encapsulation to allow several swarms to use the same UDP port. As Sec. 2 and 3 discuss the protocol at an abstract level it is (/should) not mentioned there. Do you propose to: i) have the concept of channels in all encapsulations, as the reason for reusing ports exists for e.g. TCP as well? ii) explain parts of the UDP encapsulation in Sec. 2 and 3 already? > I.e., the intention is to keep only one transport 'connection' between > two distinct peers and to allow to run multiple swarm instances at the > same time over the same transport. > And how do swarms and channels correlate? > Is this last line is a question from you, or something that should be addressed better in the draft? The answer is there is a single channel for each swarm. So if two peers A and B want to exchange chunks in multiple swarms Si (i=1...N) in parallel, there are N channels between A and B. > ***Technicals: > - Section 2.1, 2nd paragraph, about the tracker: > I haven't seen a single place where the interaction with a tracker is > discussed or where the tracker less operation is discussed in > contrast. It is further unclear what type of information is really > required from a tracker. > A tracker (or a resource directory) would need to provide more then IP > address & port, e.g., the used transport protocol for the protocol > exchange (given that other transports are allowed), used chunk size, > chunk addressing scheme, etc > The WG charter has always had a usage guide planned for describing these scenarios. Do you suggest describing them here? If so, at an abstract level detailing which information is minimally required, or very concretely referencing the tracker protocol spec? Note the latter may complicate standardization progress as the tracker protocol spec is not as far along as the peer protocol. > - Section 3.7, 2nd paragraph > - all 'MAY' are actually not right here. Please remove or replace > them with lower letters if appropriate. Are there more exact guidelines on the use of these words than RFC2119? We have used them to describe required and optional protocol behaviour, both in terms of what data fields are required and what the request/response behaviour to messages is. Using these words for optional behaviour is incorrect? In this specific paragraph, how should we indicate that replying to REQUESTs is optional? > - Section 3.10.2 > This whole section about PEX hole punching reads very, very > experimental. The STUN method is ok, but PEX isn't. > First of all, the safe behavior for a peer when it receives > unsolicited PEX messages, is to discard those messages. Second, this > unsolicited PEX messages trigger some behavior which may open an > attack vector. > The best way, but this needs more discussion, is to include to some > token in the messages that are exchanged in order to make avoid any > blind attacks here. However, this will need more and detailed > discussions of the purpose of this. > The attack issues are discussed in Sec. 13.2. Does that section sufficiently cover possible attack scenarios, and/or should parts of that discussion be moved here? > - Section 3.11 > I don't see the 'MUST send keep-alive' as a mandatory requirement, as > peers might have good reasons not to send any keep alive. Why not > saying 'A peer can send a keep-alive' and it 'MUST use the simple > datagram...' as already described. Though there is also no really > need to say MUST. > Can you give an example of why peers would not want to send keep-alives, given that peer-liveliness detection (Sec. 8.14) depends on them? > - Section 4 > The syntax definition for each of the chunk addressing schemes is > missing. This is not suitable for any specification that aims at > interoperable implementations. > So an ABNF specification should be added? > ***Editorials: > > - Section 2.1: What is the PPSP Url? > We envisioned this to be defined in a usage guide. Do you want this to be defined here? Or an example? > - Section 8.1 > 1 kibibyte is 1 kbyte? > We assumed the IETF would follow ISO/IEC 80000-13 standard to avoid the kilo = 1000 or 1024 confusion. Are we wrong? > - Section 8.14 > There is no single place where all the constants are collected and > also documented what the default values or the recommended values. Do you want a separate section with all the defaults listed? > - Section 11 > This section needs to be overhauled once the document is ready for the > IESG. The section is not wrong but can be improved to help IANA. > Can you say how can it be improved so we can do that now? Regards, Arno and Riccardo From wes@mti-systems.com Thu May 9 18:28:58 2013 Return-Path: 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 4434F21F8F6D for ; Thu, 9 May 2013 18:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EcihB2w8UBSm for ; Thu, 9 May 2013 18:28:52 -0700 (PDT) Received: from atl4mhob12.myregisteredsite.com (atl4mhob12.myregisteredsite.com [209.17.115.50]) by ietfa.amsl.com (Postfix) with ESMTP id 4988E21F8F4D for ; Thu, 9 May 2013 18:28:52 -0700 (PDT) Received: from mail.hostingplatform.com ([10.30.71.204]) by atl4mhob12.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r4A1Spfc017349 for ; Thu, 9 May 2013 21:28:51 -0400 Received: (qmail 3674 invoked by uid 0); 10 May 2013 01:28:50 -0000 Received: from unknown (HELO ?192.168.1.121?) (wes@mti-systems.com@69.81.143.143) by 0 with ESMTPA; 10 May 2013 01:28:50 -0000 Message-ID: <518C4D3C.1040302@mti-systems.com> Date: Thu, 09 May 2013 21:28:28 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Martin Stiemerling References: <517F8C7B.20106@neclab.eu> In-Reply-To: <517F8C7B.20106@neclab.eu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ppsp Subject: Re: [ppsp] AD review of draft-ietf-ppsp-peer-protocol-06 X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 01:28:58 -0000 On 4/30/2013 5:18 AM, Martin Stiemerling wrote: > 2) LEDBAT as congestion control vs. PPSPP > The PPSP peer protocol is intended for the Standards Track and relies in > a normative manner on LEDBAT (RFC 6817). LEDBAT as such is an > **experimental** delay-based congestion control algorithm. > A Standards Track protocol cannot normatively rely on an Experimental > congestion control mechanism (or RFC in general). > There are ways out of this situation: > i) Do not use ledbat: this would call for another congestion control > mechanism to be described in the PPSPP draft. > ii) Work on an 'upgrade' of the LEDBAT specification to Standards Track: > Possible, but a very long way. > iii) Agree on having PPSPP also as Experimental protocol. > > I'm currently leaning towards option iii), but this is my pure personal > opinion as an individual in the IETF. Another option would be to mark it as a DOWNREF during the IETF Last Call, right? That assumes the WG can make the case for why this is okay as a DOWNREF (e.g. wide deployment experience, and lack of cataclysms). Maybe someone can comment on whether alternatives like TFRC were investigated or not? TFRC is Standards Track, and intended for providing a smoother rate like we talked about in the past (LEDBAT may not be good for relatively rate-inelastic flows), but I don't know if the feedback it requires would be compatible with what the PPSPP framing provides or not. I also would not think it wise to change to something else that doesn't match the implemented and deployed base, unless the people implementing and deploying agree that something else is clearly better and will be implemented and deployed by them. -- Wes Eddy MTI Systems From r.petrocco@gmail.com Fri May 10 01:16:28 2013 Return-Path: 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 163A221F8B18 for ; Fri, 10 May 2013 01:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvGe--VH2qCg for ; Fri, 10 May 2013 01:16:26 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id DABE421F8A18 for ; Fri, 10 May 2013 01:16:25 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id hn3so352218wib.0 for ; Fri, 10 May 2013 01:16:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=V2X2ZD7r6dO2dccDr3Cflip4l/1r65jVs/qVnBf9L4c=; b=E/J53oAUq89WRCzp4Otoek5P/AAMNhIDJywc+PWd0g/aLJgayFMweKlfEmXlZyuSI/ fVaiy8prk3WkxD7+uWFDfeCkqIUVA0TDHiJS32AZaj7IuX7h39SFuAMaCoG/6IPFIdYx irkhn4lPEijlBS9h/hOUAsneG8u3hJsAbjyuaYSKIW8QQUMQj0DOMhgXokQ8KEzHDIOg 22AeS/SlGpI4c2CnHKlAUIyT0XeQqDC3ahf0qjIIO2u+m3t34duLyHy31S41XlLSWa8g w+Bnl0bvicpCW3k9imyQ25M33Q1jBf/oDuPqTuFthglr7ekfReo2aIzWNpFTry8H28/A RtoA== MIME-Version: 1.0 X-Received: by 10.194.133.198 with SMTP id pe6mr22856472wjb.9.1368173784998; Fri, 10 May 2013 01:16:24 -0700 (PDT) Received: by 10.194.25.197 with HTTP; Fri, 10 May 2013 01:16:24 -0700 (PDT) In-Reply-To: <518C4D3C.1040302@mti-systems.com> References: <517F8C7B.20106@neclab.eu> <518C4D3C.1040302@mti-systems.com> Date: Fri, 10 May 2013 10:16:24 +0200 Message-ID: From: Riccardo Petrocco To: Wesley Eddy Content-Type: multipart/alternative; boundary=089e01175f7d7228d204dc58c806 Cc: ppsp Subject: Re: [ppsp] AD review of draft-ietf-ppsp-peer-protocol-06 X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 08:16:28 -0000 --089e01175f7d7228d204dc58c806 Content-Type: text/plain; charset=ISO-8859-1 Dear Wesley and All, Maybe someone can comment on whether alternatives like TFRC > were investigated or not? TFRC is Standards Track, and intended > for providing a smoother rate like we talked about in the > past (LEDBAT may not be good for relatively rate-inelastic > flows), but I don't know if the feedback it requires would be > compatible with what the PPSPP framing provides or not. > We are currently looking into alternatives to LEDBAT for the PPSPP. The majority of CCs will require some small modifications to the content of the DATA and ACK messages as defined in the draft. I also would not think it wise to change to something else > that doesn't match the implemented and deployed base, unless > the people implementing and deploying agree that something > else is clearly better and will be implemented and deployed > by them. > We will also run some large experiments in a controlled environment to evaluate the effect and feasibility of the different solutions. Regards, Riccardo and Arno > > -- > Wes Eddy > MTI Systems > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp > --089e01175f7d7228d204dc58c806 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear Wesley and All,

Maybe someone can comment on whether alternatives like TFRC
were investigated or not? =A0TFRC is Standards Track, and intended
for providing a smoother rate like we talked about in the
past (LEDBAT may not be good for relatively rate-inelastic
flows), but I don't know if the feedback it requires would be
compatible with what the PPSPP framing provides or not.

We are currently looking into alternatives to LEDBAT for t= he PPSPP.
The majority of CCs will require some small modific= ations to the content
of the DATA and ACK messages as defined in the draft.

I also would not think it wise to change to something else
that doesn't match the implemented and deployed base, unless
the people implementing and deploying agree that something
else is clearly better and will be implemented and deployed
by them.

We will also run some large ex= periments in a controlled environment to
evaluate the effect and feasib= ility of the different solutions.

Regards,
=A0=A0=A0 R= iccardo and Arno
=A0

--
Wes Eddy
MTI Systems
_____________________= __________________________
ppsp mailing list
ppsp@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ppsp

--089e01175f7d7228d204dc58c806-- From wes@mti-systems.com Fri May 10 10:18:04 2013 Return-Path: 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 6086821F89FF for ; Fri, 10 May 2013 10:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r80FyED0TIPi for ; Fri, 10 May 2013 10:17:59 -0700 (PDT) Received: from atl4mhob04.myregisteredsite.com (atl4mhob04.myregisteredsite.com [209.17.115.42]) by ietfa.amsl.com (Postfix) with ESMTP id 899E521F8746 for ; Fri, 10 May 2013 10:17:59 -0700 (PDT) Received: from mail.hostingplatform.com ([10.30.71.211]) by atl4mhob04.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r4AHHwi5019593 for ; Fri, 10 May 2013 13:17:58 -0400 Received: (qmail 28207 invoked by uid 0); 10 May 2013 17:17:58 -0000 Received: from unknown (HELO ?192.168.43.65?) (wes@mti-systems.com@107.45.109.70) by 0 with ESMTPA; 10 May 2013 17:17:58 -0000 Message-ID: <518D2BB7.3060101@mti-systems.com> Date: Fri, 10 May 2013 13:17:43 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Riccardo Petrocco References: <517F8C7B.20106@neclab.eu> <518C4D3C.1040302@mti-systems.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ppsp Subject: Re: [ppsp] AD review of draft-ietf-ppsp-peer-protocol-06 X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 17:18:04 -0000 On 5/10/2013 4:16 AM, Riccardo Petrocco wrote: > Dear Wesley and All, > > Maybe someone can comment on whether alternatives like TFRC > were investigated or not? TFRC is Standards Track, and intended > for providing a smoother rate like we talked about in the > past (LEDBAT may not be good for relatively rate-inelastic > flows), but I don't know if the feedback it requires would be > compatible with what the PPSPP framing provides or not. > > > We are currently looking into alternatives to LEDBAT for the PPSPP. > The majority of CCs will require some small modifications to the content > of the DATA and ACK messages as defined in the draft. That is good to hear. I don't know if it's helpful or not, but one example of how to implement TFRC in a non-DCCP UDP-based protocol is: http://tools.ietf.org/html/draft-eddy-tsvwg-saratoga-tfrc-03 I don't think it necessarily has to be as painful as some have found in the past. > I also would not think it wise to change to something else > that doesn't match the implemented and deployed base, unless > the people implementing and deploying agree that something > else is clearly better and will be implemented and deployed > by them. > > > We will also run some large experiments in a controlled environment to > evaluate the effect and feasibility of the different solutions. Excellent! -- Wes Eddy MTI Systems From iesg-secretary@ietf.org Wed May 15 07:00:52 2013 Return-Path: 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 77A4D21F8E9A; Wed, 15 May 2013 07:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.519 X-Spam-Level: X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VE1dEHUQh4O9; Wed, 15 May 2013 07:00:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 76F3521F8F0E; Wed, 15 May 2013 07:00:51 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.45 Message-ID: <20130515140051.30111.46140.idtracker@ietfa.amsl.com> Date: Wed, 15 May 2013 07:00:51 -0700 Cc: ppsp mailing list , ppsp chair , RFC Editor Subject: [ppsp] Document Action: 'Problem Statement and Requirements of Peer-to-Peer Streaming Protocol (PPSP)' to Informational RFC (draft-ietf-ppsp-problem-statement-15.txt) X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 14:00:52 -0000 The IESG has approved the following document: - 'Problem Statement and Requirements of Peer-to-Peer Streaming Protocol (PPSP)' (draft-ietf-ppsp-problem-statement-15.txt) as Informational RFC This document is the product of the Peer to Peer Streaming Protocol Working Group. The IESG contact persons are Martin Stiemerling and Spencer Dawkins. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-ppsp-problem-statement/ Technical Summary Peer-to-Peer (P2P for short) streaming systems show more and more popularity in current Internet with proprietary protocols. This document identifies problems of the proprietary protocols, proposes the development of Peer to Peer Streaming Protocol (PPSP) including the tracker and peer protocol, and discusses the scope, requirements and use cases of PPSP. Working Group Summary There is strong consensus on the WG process in this document. Document Quality The proposed protocols are being developed and there are already at least three implementations of the PPSP tracker and peer protocol. And there are some operators planning to implement the spec after they are finished. The draft describes the requirements and problem statements for the standardization of Peer and Tracker streaming protocols that are being specified in separate documents. The Problem Statement draft is not a protocol specification so the question about implementation does not apply. However, there are already both Peer and Trackers streaming protocol implementations. Personnel Stefano Previdi (sprevidi@cisco.com) is the document shepherd, and Martin Stiemerling (martin.stiemerling@neclab.eu) is the responsible AD. From sprevidi@cisco.com Thu May 30 08:41:06 2013 Return-Path: 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 18F8221F9608 for ; Thu, 30 May 2013 08:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqwJFJgQSkyH for ; Thu, 30 May 2013 08:41:02 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 8B3A621F854E for ; Thu, 30 May 2013 08:40:55 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4UFeoMK013752 for ; Thu, 30 May 2013 17:40:50 +0200 (CEST) Received: from ams3-vpn-dhcp7960.cisco.com (ams3-vpn-dhcp7960.cisco.com [10.61.95.23]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4UFejmJ001354; Thu, 30 May 2013 17:40:46 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: stefano previdi In-Reply-To: Date: Thu, 30 May 2013 17:40:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <98C05F2A-F04A-4812-AE1E-6487A9ECA8A3@cisco.com> References: To: ppsp X-Mailer: Apple Mail (2.1283) Subject: Re: [ppsp] New Version Notification - draft-ietf-ppsp-survey-04.txt X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 15:41:06 -0000 PPSP WG, this draft has been submitted a few months ago. A substantial amount of=20= work has been done by the authors in order to updated it and we'd like=20= to move it into the publication process (Informational-RFC). We start now a WG last-call period of 2 weeks.=20 Thanks. s. On Feb 25, 2013, at 2:54 AM, Zongning wrote: > Hi, >=20 > A new revision of PPSP survey has been uploaded. Please review and = comments! >=20 > -Ning >=20 >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Monday, February 25, 2013 9:53 AM >> To: ppsp-chairs@tools.ietf.org; = draft-ietf-ppsp-survey@tools.ietf.org; >> martin.stiemerling@neclab.eu >> Subject: New Version Notification - draft-ietf-ppsp-survey-04.txt >>=20 >>=20 >> A new version (-04) has been submitted for draft-ietf-ppsp-survey: >> http://www.ietf.org/internet-drafts/draft-ietf-ppsp-survey-04.txt >>=20 >>=20 >> The IETF datatracker page for this Internet-Draft is: >> https://datatracker.ietf.org/doc/draft-ietf-ppsp-survey/ >>=20 >> Diff from previous version: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ppsp-survey-04 >>=20 >> IETF Secretariat. >=20 > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp >=20