RE: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
"Narayanan, Vidya" <vidyan@qualcomm.com> Fri, 10 October 2008 06:07 UTC
Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B92F28C117; Thu, 9 Oct 2008 23:07:00 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7263028C107; Thu, 9 Oct 2008 23:06:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.599
X-Spam-Level:
X-Spam-Status: No, score=-105.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EhaeVr6YNmeE; Thu, 9 Oct 2008 23:06:57 -0700 (PDT)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 3C79428C0EA; Thu, 9 Oct 2008 23:06:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1223618863; x=1255154863; 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<vidyan@qualcomm.com>|To: =20"Dondeti,=20Lakshminath"=20<ldondeti@qualcomm.com>,=0D =0A=20=20=20=20=20=20=20=20Richard=20Barnes=0D=0A=09<rbar nes@bbn.com>|CC:=20"p2pi@ietf.org"=20<p2pi@ietf.org>,=20" 'iesg@ietf.org'"=20<iesg@ietf.org>,=0D=0A=20=20=20=20=20 =20=20=20"ietf@ietf.org"=20<ietf@ietf.org>|Date:=20Thu, =209=20Oct=202008=2023:07:21=20-0700|Subject:=20RE:=20[p2 pi]=20WG=20Review:=20Application-Layer=20Traffic=20Optimi zation=20(alto)|Thread-Topic:=20[p2pi]=20WG=20Review:=20A pplication-Layer=20Traffic=20Optimization=20(alto) |Thread-Index:=20Ackql3Fpab68XW5QR72WonF4ySZGDgABNt7g |Message-ID:=20<BE82361A0E26874DBC2ED1BA244866B9276373F3@ NALASEXMB08.na.qualcomm.com>|References:=20<2008100620353 2.B1D673A68AF@core3.amsl.com>=0D=0A=09<BE82361A0E26874DBC 2ED1BA244866B9276373BA@NALASEXMB08.na.qualcomm.com>=0D=0A =20<48EEB19C.4000303@bbn.com>=20<48EEE549.1080208@qualcom m.com>|In-Reply-To:=20<48EEE549.1080208@qualcomm.com> |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-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5402"=3B=20a=3D"10547023"; bh=0+6fCBVuUYiM03QnPaWYwMIYrQCuT51h7Az6+bSpXOI=; b=LMxFKHIMJ1Rdd/hbIFkG5Q0Gv6wqa08YzBve5DunfuQlVEvJvepjK3dJ G+ioMj6/zWBbHUJNwV9BodQpFYCGs8i36khwV17TPrY6JONO88H27qjw8 4rgrRMMPbpe6Ls38XGvKi3Ke9LeFXRGzJfCaHiGCpcC/6uTwxRievR8Dm I=;
X-IronPort-AV: E=McAfee;i="5300,2777,5402"; a="10547023"
Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Oct 2008 23:07:26 -0700
Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9A67PuM013850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 9 Oct 2008 23:07:25 -0700
Received: from nasanexhc03.na.qualcomm.com (nasanexhc03.na.qualcomm.com [172.30.33.34]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m9A67PWB005355 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 9 Oct 2008 23:07:25 -0700
Received: from nalasexhub04.na.qualcomm.com (10.47.130.55) by nasanexhc03.na.qualcomm.com (172.30.33.34) with Microsoft SMTP Server (TLS) id 8.1.291.1; Thu, 9 Oct 2008 23:07:24 -0700
Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.13]) by nalasexhub04.na.qualcomm.com ([10.47.130.55]) with mapi; Thu, 9 Oct 2008 23:07:23 -0700
From: "Narayanan, Vidya" <vidyan@qualcomm.com>
To: "Dondeti, Lakshminath" <ldondeti@qualcomm.com>, Richard Barnes <rbarnes@bbn.com>
Date: Thu, 09 Oct 2008 23:07:21 -0700
Subject: RE: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
Thread-Topic: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
Thread-Index: Ackql3Fpab68XW5QR72WonF4ySZGDgABNt7g
Message-ID: <BE82361A0E26874DBC2ED1BA244866B9276373F3@NALASEXMB08.na.qualcomm.com>
References: <20081006203532.B1D673A68AF@core3.amsl.com> <BE82361A0E26874DBC2ED1BA244866B9276373BA@NALASEXMB08.na.qualcomm.com> <48EEB19C.4000303@bbn.com> <48EEE549.1080208@qualcomm.com>
In-Reply-To: <48EEE549.1080208@qualcomm.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "p2pi@ietf.org" <p2pi@ietf.org>, "'iesg@ietf.org'" <iesg@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
Contrary to what some people seem to have interpreted my email to mean, I did actually say that the work is needed. I was noting the lack of consensus from the last BoF and I definitely feel a second BoF is more appropriate at this time to iron out the disagreements. However, I am still not trying to block the work - I am saying that there are some critical things to alter in the charter proposal. As Lakshminath notes, the notion of "service" vs. "server" is more than a terminology issue. It is important that we consider the possibility of ALTO being provided as a distributed service, potentially in an overlay context. I also see the charter being restrictive in terms of assuming a subset of information types to be provided by the ALTO server. We need to shoot for a much more generic and extensible mechanism. Another important missing piece is the ability for peers to publish information about themselves - without that, the request/response protocol alone carries much less value. Regards, Vidya > -----Original Message----- > From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] > Sent: Thursday, October 09, 2008 10:17 PM > To: Richard Barnes > Cc: Narayanan, Vidya; p2pi@ietf.org; 'iesg@ietf.org' > Subject: Re: [p2pi] WG Review: Application-Layer Traffic > Optimization (alto) > > On 10/9/2008 6:36 PM, Richard Barnes wrote: > > On the contrary, I perceived pretty strong agreement at the > BoF that > > the ALTO problem, as expressed in the documents and > presentations, as > > an important one to solve. There was some disagreement about > > solutions, but there seemed to be agreement about the general idea > > that it would be useful to create an ALTO service that could help > > peers optimize their peer selection. > > Richard, > > The minutes > (http://www.ietf.org/proceedings/08jul/minutes/alto.txt) say > this: > > +++++++++++++++ > Many people agreed that this is important work for the IETF, also some > (less) people hummed against. Hum was inconclusive - some of the "no" > hums were (in Jon's words) vehement. > +++++++++++++++ > > Given that there was no consensus, it would have been nice if > the sponsoring AD(s) or the IESG explained what's going on, > but then transparency, it appears, is not really a goal in > this case. If the idea was to just go forward anyway, we > really wasted 3, may be 6 months. > The half measures are a waste of everyone's time. > > > > > The question of "service" versus "server" in the text is a complete > > non-issue, purely a matter of wording. > > No it is not; please see below. > > > In all of the "ALTO service" > > scenarios Vidya describes, there is ultimately a single host that > > provides ALTO information, which you might as well call an > "ALTO server". > > > > A distributed service is not necessarily provided by a single host. > > > Since it addresses an important problem, and a problem that many > > people agree is important, I support moving forward with this work. > > I for one think that there needs to be much more clarity on > the goals and the terminology before just moving forward and > producing useless RFCs. > > regards, > Lakshminath > > > > > --Richard > > > > > > > > Narayanan, Vidya wrote: > >> I am surprised to see that ALTO is being proposed for a WG > after the > >> last BoF concluded with no consensus whatsoever. I think a second > >> BoF is more appropriate than a WG on the topic at this time. That > >> said, I do see the need for this work, although I have > some comments > >> on the current direction. > >> > >> Overall, I think we should work with the notion of an ALTO > "service" > >> rather than specifically an ALTO "server". The ALTO > service may be > >> provided by a server, a cluster of distributed servers or as a > >> service in an overlay. Although some of the charter wording talks > >> about a "service" rather than a "server", there is enough > mention of > >> a "server" entity to imply a strict client-server protocol. > >> > >> As part of that, I think there are a couple of key things > that need > >> to be addressed here: > >> > >> - A protocol that allows peers (or ALTO clients) to publish > >> information about themselves as part of the ALTO service. > An example > >> of such information may be the uplink/downlink bandwidth > of the peer. > >> > >> - The ability to register information types with IANA and extend > >> these. The request/response protocol should be a generic enough > >> container for any information that peers can provide and look for, > >> plus what may be available from service providers, etc. > There may be > >> some guidelines on how such information types can be > registered and > >> we may start with default ones. > >> > >> Some further comments/questions inline. > >> > >>> -----Original Message----- > >>> From: ietf-announce-bounces@ietf.org > >>> [mailto:ietf-announce-bounces@ietf.org] On Behalf Of IESG > Secretary > >>> Sent: Monday, October 06, 2008 1:36 PM > >>> To: IETF Announcement list > >>> Cc: p2pi@ietf.org > >>> Subject: WG Review: Application-Layer Traffic Optimization (alto) > >>> > >>> A new IETF working group has been proposed in the > Applications Area. > >>> The IESG has not made any determination as yet. The > following draft > >>> charter was submitted, and is provided for informational purposes > >>> only. Please send your comments to the IESG mailing list > >>> (iesg@ietf.org) by Monday, October 13, 2008. > >>> > >>> Application-Layer Traffic Optimization (alto) > >>> ============================================= > >>> Last Modified: 2008-09-29 > >>> > >>> Current Status: Proposed Working Group > >>> > >>> Chair(s): TBD > >>> > >>> Applications Area Director(s): > >>> > >>> Lisa Dusseault (lisa at osafoundation.org) Chris Newman > >>> (Chris.Newman at sun.com) > >>> > >>> Applications Area Advisor: > >>> > >>> Lisa Dusseault (lisa at osafoundation.org) > >>> > >>> Mailing List: > >>> > >>> General Discussion: p2pi at ietf.org To Subscribe: > >>> https://www.ietf.org/mailman/listinfo/p2pi > >>> Archive: http://www.ietf.org/pipermail/p2pi/ > >>> > >>> Description of Working Group: > >>> > >>> A significant part of the Internet traffic today is generated by > >>> peer-to-peer (P2P) applications used for file sharing, real-time > >>> communications, and live media streaming. P2P > applications exchange > >>> large amounts of data, often uploading as much as > downloading. In > >>> contrast to client/server architectures, P2P applications > often have > >>> a selection of peers and must choose. > >>> > >>> One of the advantages of P2P systems comes from redundancy in > >>> resource availability. This requires choosing among download > >>> locations, yet applications have at best incomplete information > >>> about the topology of the network. Applications can > sometimes make > >>> empirical measurements of link performance, but even when > this is an > >>> option it takes time. > >>> The application cannot always start out with an optimal > arrangement > >>> of peers, thus causing at least temporary reduced performance and > >>> excessive cross-domain traffic. Providing more > information for use > >>> in peer selection can improve P2P performance and lower ISP costs. > >>> > >>> The Working Group will design and specify an Application-Layer > >>> Traffic Optimization (ALTO) service that will provide > applications > >>> with information to perform better-than-random initial peer > >>> selection. > >>> ALTO services may take different approaches at balancing factors > >>> including maximum bandwidth, minimum cross-domain traffic, lowest > >>> cost to the user, etc. The WG will consider the needs of > >>> BitTorrent, tracker-less P2P, and other applications, such as > >>> content delivery networks (CDN) and mirror selection. > >>> > >> > >> What does the above sentence mean? If we are putting such a list > >> together, we must also take into account needs from structured P2P > >> overlays such as those being specified in P2PSIP. > >> > >>> The WG will focus on the following items: > >>> > >>> - A "problem statement" document providing a description of the > >>> problem and a common terminology. > >>> > >>> - 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. > >>> > >>> - A request/response protocol for querying the ALTO service to > >>> obtain information useful for peer selection, and a format for > >>> requests and > >>> responses. The WG does not require intermediaries > between the ALTO > >>> server and the peer querying it. If the requirements analysis > >>> identifies the need to allow clients to delegate third-parties to > >>> query the ALTO service on their behalf, the WG will > ensure that the > >>> protocol provides a mechanism to assert the consent of the > >>> delegating client. > >>> > >> > >> Is this meant to allow for entities such as proxies to be > in the path? > >> > >>> - A document defining core request and response formats and > >>> semantics to communicate network preferences to applications. > >>> Since ALTO services may be run by entities with > different level of > >>> knowledge about the underlying network, such preferences may have > >>> different representations. Initially the WG will > consider: IP ranges > >>> to prefer and to avoid, ranked lists of the peers > requested by the > >>> client, information about topological proximity and approximate > >>> geographic locations. > >>> Other usages will be considered as extensions to the charter once > >>> the work for the initial services has been completed. > >>> > >> > >> Earlier, it is mentioned that the requirements document will > >> determine the types of information that are useful for P2P > >> applications. Given that, it seems premature to conclude > that the WG > >> should consider the above mentioned parameters. Also, as > I mentioned > >> earlier, I think it is essential to keep the protocol and message > >> formats extensible and allow for exchange of any > registered information type. > >> > >> Another question I have is about the assumptions around > expected peer > >> addressing models. Some of the above seems to hint at IP > addresses - > >> is this an assumption already? > >> > >>> - In order to query the ALTO server, clients must first > know one or > >>> more ALTO servers that might provide useful information. The WG > >>> will look at service discovery mechanisms that are in use, or > >>> defined elsewhere (e.g. > >>> based on DNS SRV records or DHCP options). If such discovery > >>> mechanisms can be reused, the WG will produce a document > to specify > >>> how they may be adopted for locating such servers. > >>> However, a new, general-purpose service discovery > mechanism is not > >>> in scope. > >>> > >> > >> Alternately, the clients may look for ALTO services within an > >> overlay. This can be modeled as service discovery within > the overlay > >> - I'm, however, not suggesting that we take on solutions for that. > >> > >>> When the WG considers standardizing information that the > ALTO server > >>> could provide, the following criteria are important to > ensure real > >>> feasibility. > >>> > >>> - Can the ALTO service technically provide that information? > >>> - Is the ALTO service willing to obtain and divulge that > information? > >>> - Is it information that a client will find useful? > >> > >> I'm not sure how useful it is for us to answer this question. The > >> protocol we develop simply needs to be a container for any > >> information that has a registered type and fits a certain format. > >> > >>> - Can a client get that information without excessive > privacy concerns > >>> (e.g. by sending large lists of peers)? > >>> - Is it information that a client cannot find easily some > other way? > >>> > >>> After these criteria are met, the generality of the data will be > >>> considered for prioritizing standardization work, for example the > >>> number of operators and clients that are likely to be able to > >>> provide or use that particular data. > >> > >> If we can build an extensible protocol, we don't need to > define all > >> possible kinds of information that get carried in it. > >> > >>> In any > >>> case, this WG will not propose standards on how congestion is > >>> signaled, remediated, or avoided, and will not deal with > information > >>> representing instantaneous network state. > >>> Such issues belong to other IETF areas and will be treated > >>> accordingly by the specific area. > >>> > >>> This WG will focus solely on the communication protocol between > >>> applications and ALTO servers. Note that ALTO services may be > >>> useful in client-server environments as well as P2P environments, > >>> although P2P environments are the first focus. If, in > the future, > >>> the IETF considers changes to other protocols for actually > >>> implementing ALTO servers (e.g. > >>> application-layer protocols for Internet coordinate > systems, routing > >>> protocol extensions for ISP-based solutions), such work > will be done > >>> in strict coordination with the appropriate WGs. > >>> > >> > >> I hope we can also look at the above from a generalized service > >> perspective rather than just a client-server perspective. > >> > >> Thanks, > >> Vidya > >> > >>> Issues related to the content exchanged in P2P systems are also > >>> excluded from the WG's scope, as is the issue dealing > with enforcing > >>> the legality of the content. > >>> > >>> Goals and Milestones (very tentative dates): > >>> > >>> Apr 2009: Working Group Last Call for problem statement Jun > >>> 2009: Submit problem statement to IESG as Informational Aug > >>> 2009: Working Group Last Call for requirements document Oct > >>> 2009: Submit requirements document to IESG as Informational Jan > >>> 2010: Working Group Last Call for request/response protocol Jan > >>> 2010: Working Group Last Call for usage document for > communicating > >>> network preferences Mar 2010: Submit request/response protocol to > >>> IESG as Proposed Standard Mar > >>> 2010: Submit usage document to IESG as Proposed Standard May > >>> 2010: Working Group Last Call of discovery mechanism Jul > >>> 2010: Submit discovery mechanism to IESG as Proposed Standard Aug > >>> 2010: Dissolve or re-charter > >>> > >>> Initial Drafts for Consideration > >>> - draft-marocco-alto-problem-statement-02 -- Application-Layer > >>> Traffic Optimization (ALTO) Problem Statement > >>> - draft-kiesel-alto-reqs-00 -- Application-Layer Traffic > >>> Optimization > >>> (ALTO) Requirements > >>> > >>> > >>> > >>> _______________________________________________ > >>> IETF-Announce mailing list > >>> IETF-Announce@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ietf-announce > >>> > >> _______________________________________________ > >> Ietf mailing list > >> Ietf@ietf.org > >> https://www.ietf.org/mailman/listinfo/ietf > >> > > _______________________________________________ > > p2pi mailing list > > p2pi@ietf.org > > https://www.ietf.org/mailman/listinfo/p2pi > > > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
- RE: WG Review: Application-Layer Traffic Optimiza… Narayanan, Vidya
- Re: WG Review: Application-Layer Traffic Optimiza… Sam Hartman
- RE: [p2pi] WG Review: Application-Layer Traffic O… Narayanan, Vidya
- Re: WG Review: Application-Layer Traffic Optimiza… Marshall Eubanks
- Re: [p2pi] WG Review: Application-Layer Traffic O… Enrico Marocco
- Re: [p2pi] WG Review: Application-Layer Traffic O… Lakshminath Dondeti
- Re: [p2pi] WG Review: Application-Layer Traffic O… stefano previdi
- Re: [p2pi] WG Review: Application-Layer Traffic O… Philip Levis
- Re: [p2pi] WG Review: Application-Layer Traffic O… Lisa Dusseault
- Re: [p2pi] WG Review: Application-Layer Traffic O… Alissa Cooper
- RE: [p2pi] WG Review: Application-Layer Traffic O… Narayanan, Vidya
- RE: [p2pi] WG Review: Application-Layer Traffic O… Narayanan, Vidya
- Re: [p2pi] WG Review: Application-Layer Traffic O… Marshall Eubanks
- Re: [p2pi] WG Review: Application-Layer Traffic O… Lakshminath Dondeti
- Re: [p2pi] WG Review: Application-Layer Traffic O… Enrico Marocco
- Re: [p2pi] WG Review: Application-Layer Traffic O… Lakshminath Dondeti
- RE: [p2pi] WG Review: Application-Layer Traffic O… Narayanan, Vidya
- Re: WG Review: Application-Layer Traffic Optimiza… Pekka Savola
- Re: [p2pi] WG Review: Application-Layer Traffic O… Vijay K. Gurbani
- Re: [p2pi] WG Review: Application-Layer Traffic O… Vijay K. Gurbani
- Re: [p2pi] WG Review: Application-Layer Traffic O… Laird Popkin
- Re: [p2pi] WG Review: Application-Layer Traffic O… Vijay K. Gurbani
- RE: [p2pi] WG Review: Application-Layer Traffic O… Martin Stiemerling
- RE: [p2pi] WG Review: Application-Layer Traffic O… Jan Seedorf
- Re: [p2pi] WG Review: Application-Layer Traffic O… Vijay K. Gurbani
- Re: WG Review: Application-Layer Traffic Optimiza… Lars Eggert
- Re: [p2pi] WG Review: Application-Layer Traffic O… Lars Eggert
- RE: [p2pi] WG Review: Application-Layer Traffic O… Song Haibin
- Re: [p2pi] WG Review: Application-Layer Traffic O… Laird Popkin
- Re: [p2pi] WG Review: Application-Layer Traffic O… Nicholas Weaver
- Re: [p2pi] WG Review: Application-Layer Traffic O… Karl Auerbach
- RE: [p2pi] WG Review: Application-Layer Traffic O… Narayanan, Vidya
- RE: [p2pi] WG Review: Application-Layer Traffic O… Narayanan, Vidya
- Re: [p2pi] WG Review: Application-Layer Traffic O… Ye WANG
- Re: [p2pi] WG Review: Application-Layer Traffic O… Philip Levis
- RE: [p2pi] WG Review: Application-Layer Traffic O… Song Haibin
- Re: [p2pi] WG Review: Application-Layer Traffic O… Vijay K. Gurbani
- Re: [p2pi] WG Review: Application-Layer Traffic O… Lisa Dusseault
- RE: [p2pi] WG Review: Application-Layer Traffic O… Narayanan, Vidya
- Re: [p2pi] WG Review: Application-Layer Traffic O… Laird Popkin
- Re: [p2pi] WG Review: Application-Layer Traffic O… Das, Saumitra
- RE: [p2pi] WG Review: Application-Layer Traffic O… Woundy, Richard
- RE: [p2pi] WG Review: Application-Layer Traffic O… Narayanan, Vidya
- RE: [p2pi] WG Review: Application-Layer Traffic O… Narayanan, Vidya
- Re: [p2pi] WG Review: Application-Layer Traffic O… Enrico Marocco
- Re: [p2pi] WG Review: Application-Layer Traffic O… Vijay K. Gurbani
- RE: [p2pi] WG Review: Application-Layer Traffic O… toby.moncaster
- Re: [p2pi] WG Review: Application-Layer Traffic O… Laird Popkin
- Openness for IETF-sponsored events Ted Hardie
- Re: Openness for IETF-sponsored events Andrew G. Malis
- Re: [p2pi] WG Review: Application-Layer Traffic O… Nicholas Weaver
- Re: [p2pi] WG Review: Application-Layer Traffic O… Stanislav Shalunov
- RE: WG Review: Application-Layer Traffic Optimiza… Narayanan, Vidya
- RE: [p2pi] WG Review: Application-Layer Traffic O… Yu-Shun Wang
- RE: [p2pi] WG Review: Application-Layer Traffic O… Narayanan, Vidya
- RE: [p2pi] WG Review: Application-Layer Traffic O… Yu-Shun Wang