Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
- To: Yu-Shun Wang <Yu-Shun.Wang at microsoft.com>, IESG IESG <iesg at ietf.org>
- Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
- From: "Narayanan, Vidya" <vidyan at qualcomm.com>
- Date: Thu, 23 Oct 2008 18:47:43 -0700
- Accept-language: en-US
- Acceptlanguage: en-US
- Cc: "p2pi at ietf.org" <p2pi at ietf.org>, "ietf at ietf.org" <ietf at ietf.org>
- Delivered-to: ietfarch-p2pi-web-archive at core3.amsl.com
- Delivered-to: p2pi at core3.amsl.com
- Dkim-signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan at qualcomm.com; q=dns/txt; s=qcdkim; t=1224812871; x=1256348871; 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 at qualcomm.com>|To: =20Yu-Shun=20Wang=20<Yu-Shun.Wang at microsoft.com>,=20IESG =20IESG=20<iesg at ietf.org>|CC:=20"p2pi at ietf.org"=20<p2pi at i etf.org>,=20"ietf at ietf.org"=20<ietf at ietf.org>|Date:=20Thu ,=2023=20Oct=202008=2018:47:43=20-0700|Subject:=20RE:=20[ p2pi]=20WG=20Review:=20Application-Layer=20Traffic=20Opti mization=20(alto)|Thread-Topic:=20[p2pi]=20WG=20Review: =20Application-Layer=20Traffic=20Optimization=20(alto) |Thread-Index:=20Ackn81APsSzGOXtYRR6bfTbQ+SG5OQMrVTUwACFf NfAAFNViIA=3D=3D|Message-ID:=20<BE82361A0E26874DBC2ED1BA2 44866B9284E791E at NALASEXMB08.na.qualcomm.com>|References: =20<20081006203532.B1D673A68AF at core3.amsl.com>=0D=0A=20<B E82361A0E26874DBC2ED1BA244866B9284E7855 at NALASEXMB08.na.qu alcomm.com>=0D=0A=20<43AEA9A9F7768B42A89F554F0EBF7ED82D17 8EC446 at NA-EXMSG-C102.redmond.corp.microsoft.com> |In-Reply-To:=20<43AEA9A9F7768B42A89F554F0EBF7ED82D178EC4 46 at NA-EXMSG-C102.redmond.corp.microsoft.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,5413"=3B=20a=3D"11347675"; bh=F9Pfl0YYEc6u5SzeqBug4xk1Qxrzb6aSKdjw3wyqPTM=; b=SAIa2abhK9zOdFG9pRMCCqdZF6x6zWvI+PM2LP50l+BhjYLEjH/uo9Ah sNoLS48uQnoRht5ZSfaVB6O9E0QsApvAWKtodOugKTv9ymcb2ZFY9Wh9w lk3M4mmD5WHTPAUjh72q+QfPhEH8xN38yQLSQEblGo6jznFIQmy9OfLdq o=;
- In-reply-to: <43AEA9A9F7768B42A89F554F0EBF7ED82D178EC446 at NA-EXMSG-C102.redmond.corp.microsoft.com>
- List-archive: <http://www.ietf.org/pipermail/p2pi>
- List-help: <mailto:p2pi-request@ietf.org?subject=help>
- List-id: P2P Infrastructure Discussion <p2pi.ietf.org>
- List-post: <mailto:p2pi@ietf.org>
- List-subscribe: <https://www.ietf.org/mailman/listinfo/p2pi>, <mailto:p2pi-request@ietf.org?subject=subscribe>
- List-unsubscribe: <https://www.ietf.org/mailman/listinfo/p2pi>, <mailto:p2pi-request@ietf.org?subject=unsubscribe>
- References: <20081006203532.B1D673A68AF at core3.amsl.com> <BE82361A0E26874DBC2ED1BA244866B9284E7855 at NALASEXMB08.na.qualcomm.com> <43AEA9A9F7768B42A89F554F0EBF7ED82D178EC446 at NA-EXMSG-C102.redmond.corp.microsoft.com>
- Sender: p2pi-bounces at ietf.org
- Thread-index: Ackn81APsSzGOXtYRR6bfTbQ+SG5OQMrVTUwACFfNfAAFNViIA==
- Thread-topic: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
Hi Yushun,
<snip>
> >
> > Add: "Peer selection is also a problem that has many different
> > applications in p2p systems - e.g., identifying the best peer to
> > download content from, identifying the best super peer to
> contact in a
> > system, using the best relay for NAT traversal, identifying
> the best
> > next hop for a query based on several criteria (e.g., quality,
> > reputation, semantic expertise, etc.), etc."
>
> I actually think the proposed addition is somewhat redundant,
> and could easily lead into ratholes on what are the metrics
> for "best" and whether it is even possible to get the best.
> The current charter tries to avoid that by saying
> "better-than- random" selection gating mostly on getting
> better performance and lowering the costs (as two examples).
> Also, what's the "best" depends heavily on whom you ask.
> ISP's notions of "best"
> may not align with those of the end users.
>
> I am fine with the examples (targets for selections), but
> let's try to avoid the debates on "best" again.
>
I'm fine with that. I agree that "best" is a relative word and causes confusion at best :)
<snip>
>
> > > Other usages will be considered as extensions to the charter once
> > > the work for the initial services has been completed.
> >
> > I think we should delete the sentence above.
>
> While it may seem redundant, I don't see anything wrong with
> that. It just means we may have a narrow scope now, but we
> will think about new extensions once we are done.
>
I actually believe that if we designed the protocols right, we don't need a recharter to carry other types of information - we can allow registration of new information types for ALTO beyond the life of the WG.
<snip>
>
> I read the list below somewhat differently. These are not for
> relative importance of the information, but kind of a min bar
> for what we want to do. While some may need re-wording, the
> intent is fine, IMO.
>
I'm not so sure. Basically, it is a question of what usage these are evaluated based on. Let's take a couple of examples. Whether the ALTO service can provide a piece of information is dependent on various factors - some things are dependent on whether such information is available from other places today (e.g., topology or ASNs, etc.); I think this set of questions has been written with that mindset. But, there are others (e.g., quality, reputation, semantic expertise, etc.) that are totally based on the type of the p2p overlay and whether clients can provide that information. Similarly, whether some information is useful to a client is totally contextual to the application as well.
> > > - 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?
> > > - 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.
> >
> > The above again gets into our evaluation of what is
> important based on
> > what we know today and is limiting.
>
> This point does need some clarification and rewording.
>
> Thanks,
> yushun
>
>
_______________________________________________
p2pi mailing list
p2pi at ietf.org
https://www.ietf.org/mailman/listinfo/p2pi
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.