Re: [ppsp] [decade] Object naming in -req and -arch

Arno Bakker <arno@cs.vu.nl> Fri, 13 July 2012 07:12 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 7E4F421F8795; Fri, 13 Jul 2012 00:12:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.535
X-Spam-Level:
X-Spam-Status: No, score=-1.535 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, 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 2UasvDiPPu2y; Fri, 13 Jul 2012 00:12:00 -0700 (PDT)
Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.18]) by ietfa.amsl.com (Postfix) with ESMTP id 870D021F8790; Fri, 13 Jul 2012 00:12:00 -0700 (PDT)
Received: from PEXHB012A.vu.local (130.37.236.66) by mailin.vu.nl (130.37.164.18) with Microsoft SMTP Server (TLS) id 14.2.298.4; Fri, 13 Jul 2012 09:12:32 +0200
Received: from [192.168.0.104] (130.37.238.20) by mails.vu.nl (130.37.236.66) with Microsoft SMTP Server (TLS) id 14.2.298.4; Fri, 13 Jul 2012 09:12:34 +0200
Message-ID: <4FFFCA6D.7060306@cs.vu.nl>
Date: Fri, 13 Jul 2012 09:12:45 +0200
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: Peng Zhang <pzhang.thu@gmail.com>
References: <20120710162606039401143@chinamobile.com> <2039343B-5F6B-4777-864E-B4F00B5A258E@gmail.com> <4FFE6D67.80705@cs.vu.nl> <D282B585-33DD-4A0D-8CD3-9CF525C56446@gmail.com>
In-Reply-To: <D282B585-33DD-4A0D-8CD3-9CF525C56446@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [130.37.238.20]
Cc: ppsp <ppsp@ietf.org>, decade <decade@ietf.org>
Subject: Re: [ppsp] [decade] Object naming in -req and -arch
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: Fri, 13 Jul 2012 07:12:01 -0000

On 12/07/2012 22:28, Peng Zhang wrote:
>
> On Jul 12, 2012, at 2:23 AM, Arno Bakker wrote:
>
>> The gains of using MHT depend on the chunk size. For PPSP we prefer
>> chunks of 1K that fit in an UDP packet carried over Ethernet. In
>> that case, for a 4 GB file, there are 4 M chunks, resulting in 80
>> MB of leaf hashes when SHA1 is used. Transferring that beforehand
>> as in BitTorrent definitely increases latency ;o)
> Yes, if the chunk size is only 1KB, and each chunk is verified
> individually, we cannot afford to send all hashes beforehand. While
> in the worst case without optimization, almost 2*80M = 160M hashes
> needs to be sent to the receiver, will that be a large overhead
> compared to 4G? Do we really need such a small chunk size? Maybe I
> miss some previous discussion on this.

Hi

For PPSP we want to use UDP as we don't need the in-order and 
reliability features of TCP, and want flexibility to use differnet 
congestion control algorithms and handle NATs. With Ethernet as the 
dominant MAC layer at present and an unreliable transport we don't want 
datagrams to exceed the Ethernet MTU, otherwise the chance of losing a 
datagram increases (an UDP packet taking N IP packets will not be 
delivered when only 1 IP packet is lost). Hence, we use chunks of ~1K.

A good practice in P2P networks is to not forward data you have not 
verified. So to forward the 1K chunks directly we need to be able to 
verify their integrity at this granularity, enter Merkle Hash Trees.
We think the resulting overhead due to the size of the tree is 
acceptable, as it is easy to optimize the number of hashes transmitted
in our use cases.

CU,
     Arno