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

Vijay Gurbani <vijay.gurbani@gmail.com> Tue, 07 July 2020 18:54 UTC

Return-Path: <vijay.gurbani@gmail.com>
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 C20303A03FA for <alto@ietfa.amsl.com>; Tue, 7 Jul 2020 11:54:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 wulzHg8kGWMt for <alto@ietfa.amsl.com>; Tue, 7 Jul 2020 11:54:43 -0700 (PDT)
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A3C03A0112 for <alto@ietf.org>; Tue, 7 Jul 2020 11:54:42 -0700 (PDT)
Received: by mail-ej1-x630.google.com with SMTP id dp18so47730408ejc.8 for <alto@ietf.org>; Tue, 07 Jul 2020 11:54:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2iZso1OUJulcPhuMYra6cSw3l/xSuQnFtGfOK5b2M9I=; b=WIdSBgiTSZme2SVcS8nTK4TuaXF86yMv0YieDxWB1kxrZp5FHfztUxgOM50uFwDu+k q6IZHcfuY4HZQRozXTxwC1SQLGstuWrtePC0oJK5AubA8o7RXmW8ho1fuHej7NbL9dSG TTkEb0rzp/2s9GFhf/mtNPyl6/Xd+FtVkDIesTAqxK8AwJal0qAOxwhzi3uwFv9CQKnu N+z487hM/nAbd1P4Nu6ycYz2H9FTNkwEKF4vKycyWQCuLuKtAsD8O/Fnrt98s+JBqGuQ XNHLUzhlh7jY++hW1WqrjEA+uNGkg/+w/kU+L3pfPJkayXpnz3tC2BCPCkqYN9QT/iUL 9lTA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2iZso1OUJulcPhuMYra6cSw3l/xSuQnFtGfOK5b2M9I=; b=otVtKHEkDd4OU7fpv0UPWAs4c5XZfFmmZQacXM1wF/2N13MP+7EuR5CrQ2FNBy3670 tWNfjvD+4gwQmqidwp+sSSA8sncpNePDyEa8N/cq4EtE2jVNqsy4jlZ2QZH2A0ugrCmI /6aA8WjdtP2YrhIy17sMvCkS6KgmylPH9muxsEJpuC+ddhxdgWsSQ7PbmK8nSVeXGw2q M4codAKOAWhdcWA8mf65igzWVpw4xGU5Up/jP0B/0KtuXApbvsMNPOtHL/CB/HVD4Urq /vlFw7kVtKtD262Mrn1bXNyyPT6vAu/GjJl+XiBNhAy4LPnMhXGv0U33UCYAz+ysCSUF us7Q==
X-Gm-Message-State: AOAM530HK209AXDSjWAZGdrE7FflAb1L5IkHIhkHm43bdJ/ZHx7uw5bk Le15Uv5CDPGLcxCr++2PfkhfjoIZEkuU090dUat71g==
X-Google-Smtp-Source: ABdhPJwsP7xeN7zt+AU/YgMga9d3ITWg6F82hG30UJTDTfUHCdNcf/DQunAJhFZnpRHRwzZxIs0Ihr3zXv301pRSt2s=
X-Received: by 2002:a17:906:3650:: with SMTP id r16mr46864352ejb.465.1594148081466; Tue, 07 Jul 2020 11:54:41 -0700 (PDT)
MIME-Version: 1.0
References: <VI1PR04MB4717F91DEB54D11C0B828D00B26A0@VI1PR04MB4717.eurprd04.prod.outlook.com>
In-Reply-To: <VI1PR04MB4717F91DEB54D11C0B828D00B26A0@VI1PR04MB4717.eurprd04.prod.outlook.com>
From: Vijay Gurbani <vijay.gurbani@gmail.com>
Date: Tue, 07 Jul 2020 13:53:33 -0500
Message-ID: <CAMMTW_Jy9cwXHx+ND5uhFgNDMradDP9A0hNCfryvGSEe1jxx-w@mail.gmail.com>
To: Paulo Edgar Mendes Caldas <a79089@alunos.uminho.pt>
Cc: "alto@ietf.org" <alto@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001d8aee05a9de86f7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/pzw5xqv8jZwkck5tMwlRYSmX-D0>
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 18:54:45 -0000

Generally, the answer to the question of how a protocol is policed (or
enforced) is that it isn't (policed or enforced).  There is no "protocol
police" that will impose punitive measures on non-behaving clients.

Also generally speaking, well-behaving clients will have an automatic
incentive to continue to behave well since doing so benefits them in some
manner (shorter latencies, shorter download time, etc.).  Similarly, for
the server to disseminate bogus information (as you point in your email)
implies that the entire system will be unused since clients will not prefer
to use guidance that provides sub-optimal performance.  So from a
cost-effort point of view, the system reaches an equilibrium, whether or
not this is a unique Nash equilibrium or there are multiple Nash equilibria
is subject for an academic paper.  Clearly, if a client (or server) pursues
a dominant strategy and is greedy at all times, the value of the overall
system decreases.

Cheers,

- vijay

On Tue, Jul 7, 2020 at 1:44 PM Paulo Edgar Mendes Caldas <
a79089@alunos.uminho.pt> 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
>