Re: [alto] Question regarding voluntary nature of ALTO clients

Sebastian Kiesel <ietf-alto@skiesel.de> Tue, 07 July 2020 19:26 UTC

Return-Path: <ietf-alto@skiesel.de>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD7893A092F for <alto@ietfa.amsl.com>; Tue, 7 Jul 2020 12:26:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MaVbrqVm3fdm for <alto@ietfa.amsl.com>; Tue, 7 Jul 2020 12:26:08 -0700 (PDT)
Received: from mx10.wurstkaes.de (mx10.wurstkaes.de [IPv6:2a02:a00:e000:116::41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49AAF3A087C for <alto@ietf.org>; Tue, 7 Jul 2020 12:26:07 -0700 (PDT)
Received: from l1.wurstkaes.de ([2a02:a00:e000:116::c1]:35754) by mx10.wurstkaes.de with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <ietf-alto@skiesel.de>) id 1jstEC-0002sb-JG; Tue, 07 Jul 2020 21:26:04 +0200
Date: Tue, 07 Jul 2020 21:26:01 +0200
From: Sebastian Kiesel <ietf-alto@skiesel.de>
To: Paulo Edgar Mendes Caldas <a79089@alunos.uminho.pt>
Cc: "alto@ietf.org" <alto@ietf.org>
Message-ID: <20200707192601.GA31794@l1.wurstkaes.de>
References: <VI1PR04MB4717F91DEB54D11C0B828D00B26A0@VI1PR04MB4717.eurprd04.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <VI1PR04MB4717F91DEB54D11C0B828D00B26A0@VI1PR04MB4717.eurprd04.prod.outlook.com>
Organization: my personal mail account
Accept-Languages: en, de
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/S84unwjlXZoyY42XGx5m1ZqB6eU>
Subject: Re: [alto] Question regarding voluntary nature of ALTO clients
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/alto/>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Jul 2020 19:26:11 -0000

Hi Paulo,

when the IETF ALTO working group started some 12 years ago, there was
the expectation (or assumption) that in the P2P use case, this
win-win-situation (better performance in the overlay, less resource
utilization in the underlying infrastructure) would happen on its own.
The core business of IETF is to standardize protocols to ensure
interoperability between different implementations. Other parts of the
overall P2P traffic optimization problem were not in our main focus,
such as developing and fine-tuning a peer selection algorithm that would
make use of the ALTO information, or mechanisms to punish misbehaving
peers.  Back in 2008, it was not uncommon that ISPs would throttle the
bandwidth for residential customers that exceeded a certain threshold of
data volume per month. This scheme could be modified from just counting
bytes to multiplying each byte with its respective routing cost. Following
the ALTO advice would have been a strategy for users to avoid throttling.

It should also be noted, that while the work on the protocol went on,
the focus with respect to use cases shifted - from the "unmanaged" P2P
networks (where no single entity is legally responsible for the overall
operation and traffic distribution in the overlay) to more managed
overlays such as content delivery networks (CDN) or big data
applications for science (there, there might be someone to call if the
overlay does the opposite of what the ALTO server suggests to do). 

best regards,
Sebastian

On Fri, Jul 03, 2020 at 08:25:04AM +0000, Paulo Edgar Mendes Caldas wrote:
> Good morning,
> 
> I am currently doing investigative work regarding the ALTO protocol for my master's degree. I've been getting acquainted with the ALTO protocol and the problems it tries to solve via reading of the RFCs and drafts that have been published, but I've struggled to find a question to the following - does the ALTO system as a whole have a plan on how to guarantee that the clients act in good faith with the information they receive?
> 
>  In particular, consider that a P2P application wishes to have ALTO guidance to pick between a number of potential number of peers, and thus queries for a multi-cost map for the pairs (source_pid, destination_pid) whose throughput and one-way-delay values are within a certain criteria. Is there anything preventing said client to then not prefer the pair whose routing cost is lowest? It would make sense that the ALTO server would prefer that the client would "be kind" and cooperate with the ISP and use the information in a way that is mutually beneficial, but what if the client only cares about client performance?
> 
> I can only imagine one of the following solutions - there being some incentive mechanism, restricting the information to trustworthy partners, or deliberately manipulating non-routing-cost metric values to steer clients into a certain choice. The latter seems problematic as it breaks the transparency in layer cooperation and might damage the entire reason the system was created to begin with.
> 
> Is there any work done in regards to ensuring client cooperative behavior?
> 
> Kind regards,
> 
> Paulo Caldas

> _______________________________________________
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto