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

"Woundy, Richard" <> Thu, 16 October 2008 19:33 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 8905B3A6A7D; Thu, 16 Oct 2008 12:33:26 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id BBDD53A6A6B; Thu, 16 Oct 2008 12:33:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.37
X-Spam-Status: No, score=0.37 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, SARE_FWDLOOK=1.666]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dSqo4+upn8Dn; Thu, 16 Oct 2008 12:33:23 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8A8EE3A6452; Thu, 16 Oct 2008 12:33:23 -0700 (PDT)
Received: from ([]) by with ESMTP id KP-NTF18.61622455; Thu, 16 Oct 2008 15:34:07 -0400
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Oct 2008 15:34:07 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 16 Oct 2008 15:34:06 -0400
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
Thread-Index: Acku9XWB0IwKs4r6Siyxc25RnVcIeAAHltmQACuntKA=
References: <><><><><><><><> <>
From: "Woundy, Richard" <>
To: "Narayanan, Vidya" <>, "Lisa Dusseault" <>, "Vijay K. Gurbani" <>
X-OriginalArrivalTime: 16 Oct 2008 19:34:07.0714 (UTC) FILETIME=[27F49420:01C92FC6]
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-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit


>This would be a big mistake on our part.  b) is not a research problem
and it is very much related to the same problem being solved in ALTO.

Personally, I can see that there is value in "b): information that peers
decide to make available about themselves to other peers for this
purpose". Your example below was information about whether a client is
on a wireless network. In an earlier thread, I had suggested that
clients may want to reveal their "available access bandwidth" in a
similar fashion; see
<>. So
even as an "ISP person", I can see where you are coming from.

But if I am interpreting RFC 2418 correctly
<>, it is not sufficient to decide if
"b)" is a worthy IETF activity, but that there are enough participants
working on "b)" for an IETF effort to be successful. Quoting from parts
of RFC 2418 section 2.1:

"Is there sufficient interest within the IETF in the working group's
topic with enough people willing to expend the effort to produce the
desired result (e.g., a protocol specification)?"

"Is there enough expertise within the IETF in the working group's topic,
and are those people interested in contributing in the working group?"

"Does a base of interested consumers (end-users) appear to exist for the
planned work?  Consumer interest can be measured by participation of
end-users within the IETF process, as well as by less direct means."

You said:

>Given that Lisa is looking for solutions, I almost wish I have a
solution thought out :) But, I don't.

Are you volunteering to work on requirements and/or solutions for "b)"?
Would others?

(I may be interested and supportive in the future, although right now I
am predictably focused on activities related to "a)".)

If there isn't a quorum to work on "b)" right now, this could be
revisited in the future with a re-charter of ALTO, when such a quorum
does exist.

If there is a quorum, it would be helpful to hear about it.

-- Rich

-----Original Message-----
From: [] On Behalf Of
Narayanan, Vidya
Sent: Wednesday, October 15, 2008 7:48 PM
To: Lisa Dusseault; Vijay K. Gurbani
Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization


> There's plenty of work to do in a).  My recommendation based
> on estimation of appropriate scope as well as an estimation
> of the consensus here, would be to do that first -- to have a
> charter that is scoped to (a).  Then the possibilities for
> (b) include working in the P2P research group, individual
> submissions, and /or a new BoF/WG.  Another option would be a
> future charter update for ALTO if it's successful and there's
> consensus for it to be the basis for (b).

This would be a big mistake on our part.  b) is not a research problem
and it is very much related to the same problem being solved in ALTO.
Letting each p2p application come up with its own mechanism of doing b)
only kills the interoperability and extensibility.  We keep talking
about scope creep here, but, we seem to miss something critical.  By not
keeping the related problems together in producing solutions, we are
only increasing the number of different mechanisms that are going to be
needed in future to provide this one service - I cannot understand why
that is a good thing.

Without allowing for b), I think information that a) gives you can be
more or less useless in some circumstances.  Let me provide some
additional context here.  One of the pieces of information that is
important to allow wireless devices to participate in p2p networks is
the basic fact that a given node is wireless.  This may place some
fundamentally different criteria on path selection decisions that cannot
be deduced simply with topology information.

For any forward looking work we do at the IETF, we must stop designing
just for wired (and stationary) devices.  These are the designs that
tend to look horrible when adapted to the wireless (and mobile) world
and I seriously hope that that is not where we are headed with this

Best regards,

> Lisa
p2pi mailing list
p2pi mailing list