Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)

Pekka Savola <> Tue, 21 October 2008 20:28 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 5FDB728C1BE; Tue, 21 Oct 2008 13:28:31 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id AC69E3A6BA1; Mon, 13 Oct 2008 05:22:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.425
X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Hf45rhrvz8dl; Mon, 13 Oct 2008 05:22:44 -0700 (PDT)
Received: from ( [IPv6:2001:670:86:3001::1]) by (Postfix) with ESMTP id 930253A6B9B; Mon, 13 Oct 2008 05:22:41 -0700 (PDT)
Received: from (localhost []) by (8.13.8/8.13.8) with ESMTP id m9DCNK6e030841; Mon, 13 Oct 2008 15:23:20 +0300
Received: from localhost (pekkas@localhost) by (8.13.8/8.13.8/Submit) with ESMTP id m9DCNJlJ030838; Mon, 13 Oct 2008 15:23:20 +0300
Date: Mon, 13 Oct 2008 15:23:19 +0300 (EEST)
From: Pekka Savola <>
In-Reply-To: <>
Message-ID: <>
References: <>
User-Agent: Alpine 2.00 (LRH 1167 2008-08-23)
MIME-Version: 1.0
X-Virus-Scanned: ClamAV 0.93.3/8414/Sun Oct 12 06:30:50 2008 on
X-Virus-Status: Clean
X-Mailman-Approved-At: Tue, 21 Oct 2008 13:28:30 -0700
Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: P2P Infrastructure Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"

On Mon, 6 Oct 2008, IESG Secretary wrote:
> - A requirements document.  This document will list requirements for
> the ALTO service, identifying, for example, what kind of information
> P2P applications will need for optimizing their choices.

I believe this work could be useful and would provide an improvement 
over existing p2p usage and traffic management.

I'd be more comfortable with this effort if a recharter (this is a 
rather lightweight process) was needed after finishing the problem 
statement and the requirements.  It would also encourage that people 
actually put some serious work on those before diving into solutions 

There are significant design issues that will come up in the protocols 
and I'd expect that it would be helpful if those had already been 
dealt with in the requirements phase.

For example, the current req document has:

    REQ. 4: ALTO Clients MUST be able to find out where to send ALTO

.. and the charter lists DHCP option or SRV record as examples.  Both 
of these have issues in certain contexts.  For example, must this 
discovery mechanism work across unmodified NAT boxes?  DHCP option 
doesn't; SRV record in many contexts doesn't either (or otherwise 
you'll end up with the same "how to you discover the domain name under 
which you should look?" problem).

Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
p2pi mailing list