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

"Narayanan, Vidya" <> Fri, 17 October 2008 20:56 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 803CE28C122; Fri, 17 Oct 2008 13:56:46 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8666C3A6AF6; Fri, 17 Oct 2008 13:56:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.464
X-Spam-Status: No, score=-102.464 tagged_above=-999 required=5 tests=[AWL=-1.531, BAYES_00=-2.599, SARE_FWDLOOK=1.666, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cNSRZax6lTEH; Fri, 17 Oct 2008 13:56:43 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6E1333A6AF4; Fri, 17 Oct 2008 13:56:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=qcdkim; t=1224277068; x=1255813068; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20<>|To: =20"Woundy,=20Richard"=20< m>,=0D=0A=20=20=20=20=20=20=20=20Lisa=20Dusseault=0D=0A =09<>,=0D=0A=20=20=20=20=20=20=20 =20"Vijay=20K.=20Gurbani"=20<>|CC: =20""=20<>,=20"" =20<>|Date:=20Fri,=2017=20Oct=202008=2013:57 :44=20-0700|Subject:=20RE:=20[p2pi]=20WG=20Review:=20Appl ication-Layer=20Traffic=20Optimization=20(alto) |Thread-Topic:=20[p2pi]=20WG=20Review:=20Application-Laye r=20Traffic=20Optimization=20(alto)|Thread-Index:=20Acku9 XWB0IwKs4r6Siyxc25RnVcIeAAHltmQACuntKAANLNEEA=3D=3D |Message-ID:=20<BE82361A0E26874DBC2ED1BA244866B92763795B@>|References:=20<2008100620353><BE82361A0E26874DBC2ED1BA244><48EFA1B7.70105><BE82361A0E26874DBC2ED1BA244866B927><48F36E15.2000408@alca><BE82361A0E26874DBC2ED1BA244866B927637717@><48F60A4F.3010604@alcatel-luc><ca722a9e0810151139q29705f8bm9e02ab5eb0dd27ec@mai>=0D=0A=20<BE82361A0E26874DBC2ED1BA244866B9276>=0D=0A=20<74CCBBDF76102 m>|In-Reply-To:=20<74CCBBDF76102846AFA7B29F3A98D3F6028962>|Accept-Language:=20en- US|Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5408"=3B=20a=3D"11032789"; bh=zI6K+SAqGQLmuVI4Ty5d+5Hm+O1VrpbotdNS79El8jc=; b=v96f3oOkBkplnYrdRR+Am5TBPtQyj4u5ReFq6nSnJ1rNxl9MyaKRVwkA 98MVSv8b4UZGssG7h81qfhgGQpe+MSt9UR4yfDhoTmAHYB+3/+2N/cU3j 0KMWkhGsEmVD99uDd7suX6QYnSp1V10FeXw7YTL1Vy1iGCbqlYnsdWM82 4=;
X-IronPort-AV: E=McAfee;i="5300,2777,5408"; a="11032789"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Oct 2008 13:57:47 -0700
Received: from ( []) by (8.14.2/8.14.2/1.0) with ESMTP id m9HKvluF009387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 17 Oct 2008 13:57:47 -0700
Received: from ( []) by (8.14.2/8.14.2/1.0) with ESMTP id m9HKvkVP018631 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 17 Oct 2008 13:57:47 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Fri, 17 Oct 2008 13:57:46 -0700
Received: from ([]) by ([]) with mapi; Fri, 17 Oct 2008 13:57:46 -0700
From: "Narayanan, Vidya" <>
To: "Woundy, Richard" <>, Lisa Dusseault <>, "Vijay K. Gurbani" <>
Date: Fri, 17 Oct 2008 13:57:44 -0700
Thread-Topic: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
Thread-Index: Acku9XWB0IwKs4r6Siyxc25RnVcIeAAHltmQACuntKAANLNEEA==
Message-ID: <>
References: <><><><><><><><> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "" <>, "" <>
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

To answer your question about participation, I can definitely volunteer to work on the requirements and solution for this effort.  We will try to produce a draft explaining the problem and need for peer participation in ALTO by the deadline for Minneapolis.

With respect to process, I think this one takes the cake among abominations.  Having been at the IETF long enough and having participated in several BoFs, I'm quite familiar with RFC2418 and the process.  Here we have an effort that started with a closed/gated workshop outside the IETF, was brought into the IETF as a BoF in RAI that ended in an inconclusive manner and transitioned now into a WG proposal for APP with little to no explanation to the wider audience on the rationale.  So, it may be best if we didn't really get into the process discussion with this effort.

I'm just hoping that at this stage, the ADs are going to hear all opinions and also use technical judgment on the relative points that are being made.

Best regards,

> -----Original Message-----
> From: Woundy, Richard []
> Sent: Thursday, October 16, 2008 12:34 PM
> To: Narayanan, Vidya; Lisa Dusseault; Vijay K. Gurbani
> Cc:;
> Subject: RE: [p2pi] WG Review: Application-Layer Traffic
> Optimization (alto)
> Vidya,
> >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
> <
ml>. 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
> Cc:;
> Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization
> (alto)
> Lisa,
> >
> >
> > 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 work.
> Best regards,
> Vidya
> > Lisa
> >
> _______________________________________________
> p2pi mailing list
p2pi mailing list