Re: [PANRG] An earlier draft on signaling between network and end-hosts

Todd Hubers <todd.hubers@gmail.com> Sat, 10 November 2018 01:16 UTC

Return-Path: <todd.hubers@gmail.com>
X-Original-To: panrg@ietfa.amsl.com
Delivered-To: panrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00FDA130DFE for <panrg@ietfa.amsl.com>; Fri, 9 Nov 2018 17:16:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.998
X-Spam-Level:
X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 2vz8wwX-bMG3 for <panrg@ietfa.amsl.com>; Fri, 9 Nov 2018 17:16:54 -0800 (PST)
Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 85FFF130DF9 for <panrg@irtf.org>; Fri, 9 Nov 2018 17:16:54 -0800 (PST)
Received: by mail-io1-xd31.google.com with SMTP id a5-v6so2597430ioq.8 for <panrg@irtf.org>; Fri, 09 Nov 2018 17:16:54 -0800 (PST)
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=4sH89Dw8tBm71y7wma3vf/kALME9yWwh4HRT4KyxUBc=; b=jc5GF4CDnTUBNnOckPsmLMqepwb+CmWTk0itGARVyy8ywzWc9Q0nDioOkRpOprwz5X QHRGokD2nNN6WvsM4HnFNgk0ePTnM3wDQPFzDvFV4xy2XeLbXC33IpGFC6R+yz5S6++I q70pjD+/3QapUSJ5eONFE5KvHUcLxTQihPVCmFg+2lXOCfDMLvrspprCR27V/uliOXls NdKb+grwb3+9g7x23gFeNgk3U+TlCWFJa7BCnf8qjSNoS9DGJUsxL+t4TckpFooftGEZ KrNAR1BglMAdPyCB2ntatD39JWcHk+TpH7+sZBrT/2SVeqRDjhvUlRu+7KHvxaJQgDe9 tomQ==
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=4sH89Dw8tBm71y7wma3vf/kALME9yWwh4HRT4KyxUBc=; b=AKuZc7mblGrn0BBML/0FxWmhSUrOoYtqoAGOn+fLkxsgZES/GHGj+/hx5pQWMQraA3 lkiOeYTYnOVCA2T0hpBfLt6axiBMl1PW15BPSFgqUYTyHHrYbvXNWEem19HwMQ8MH9/q zJ03Ad/3qY1U66oIPK824WMiIWb9obFO1KvwxicNTUAvFFxFouuJM3h0YmDxYnTZMd0y ssri8pechLu2mYKIxXj9zMxFiuGgz+Ymt7wjlHVcpWDISE34/W4hZ0lnQab3sqWO4jcY brzZ6KrZX1GN9MGFZUWeHxAqidClGWUn9QApw9Rv4XFRSTHK6VPUVYv7KF2DRWhmfA8Q 7N0g==
X-Gm-Message-State: AGRZ1gJB7AyA6mlNcXTwpyScc3JOSd9x0EGSc4tgVf+ehoeh7TTYbtmN J5J8m54wAkTt9vSniBn0DTo42M7GnAPWzegY2qA=
X-Google-Smtp-Source: AJdET5cgdMxFnAn2nPKUWh//lOOcRFKRp8mnwF9E08tDz/ieAEe645Nq6q79ofbZeXi0rjc31WawitIdmJ5Xrzuwbs0=
X-Received: by 2002:a6b:b5d5:: with SMTP id e204-v6mr8271561iof.233.1541812613720; Fri, 09 Nov 2018 17:16:53 -0800 (PST)
MIME-Version: 1.0
References: <alpine.DEB.2.20.1811081147180.10713@hp8x-60.cs.helsinki.fi> <CAKKJt-eO2HiJLu3hw=ZFAgQ+panNw=3PrqV2N8EYM4eoL=ZLsA@mail.gmail.com> <CABO3BC1Sy36YLvRowQPRW6gg7W3+vrCDcUZGWp8s5GmT1=riRw@mail.gmail.com> <6EC6417807D9754DA64F3087E2E2E03E2D152C26@rznt8114.rznt.rzdir.fht-esslingen.de>
In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D152C26@rznt8114.rznt.rzdir.fht-esslingen.de>
From: Todd Hubers <todd.hubers@gmail.com>
Date: Sat, 10 Nov 2018 12:16:40 +1100
Message-ID: <CABO3BC2Oqr=Fyou8n+L8384eHrWm0_xBgkw07MVy0pMTPYtjSA@mail.gmail.com>
To: Michael.Scharf@hs-esslingen.de
Cc: panrg@irtf.org, spencerdawkins.ietf@gmail.com
Content-Type: multipart/alternative; boundary="00000000000026b164057a4539ad"
Archived-At: <https://mailarchive.ietf.org/arch/msg/panrg/WveGIT_EZYJ2qhX7uNKcXx37O7E>
Subject: Re: [PANRG] An earlier draft on signaling between network and end-hosts
X-BeenThere: panrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Path Aware Networking \(Proposed\) Research Group discussion list" <panrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/panrg>, <mailto:panrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/panrg/>
List-Post: <mailto:panrg@irtf.org>
List-Help: <mailto:panrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/panrg>, <mailto:panrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Nov 2018 01:16:57 -0000

Thanks Michael,

At first glance, RFC 7971 is centralised around P2P data resource sharing.
I have another scheme in mind which I would like to draft one day that may
be superior in some cases. This RFC certainly does then propose the use of
multiple layers in the network to accomplish its goals. However, it then
lists problems that presumably a multi-layer solution would be fixing.

 The discrepancies are due to various reasons, including, but not limited
> to the following facts:
>    o  The ALTO service is not an admission control system.
>    o  The ALTO service
>
> * **may not know the instantaneous congestion status      of the
> network.***
> *      of the network.***   o  The ALTO service
>
> * **may not know all link bandwidths**, i.e., where the      bottleneck
> really is, and there may be shared bottlenecks.*
> *      bottleneck really is, and there may be shared bottlenecks.*   o
>  The ALTO service
>
> ***may not have all information about the actual      routing***
> *      routing***   o  The ALTO service
>
> ***may not know whether the candidate endpoint      itself is overloaded***
> *      itself is overloaded***   o  The ALTO service
>
> ***may not know whether the candidate endpoint      throttles the
> bandwidth it devotes for the considered application***
> *      throttles the bandwidth it devotes for the considered application***
>  o  The ALTO service
>
>
> ***may not know whether the candidate endpoint will      throttle the data
> it sends to the client (e.g., because of some      fairness algorithm, such
> as tit for tat).***
> *      throttle the data it sends to the client (e.g., because of some**
>     fairness algorithm, such as tit for tat).***


For this reason, it is my opinion that the title of the RFC is a misnomer:
"Application-Layer Traffic Optimization...". However, I do expect to find
some useful ideas, references, and considerations, and I thank you for
bringing this to my attention.

I hope to find as many similar RFCs as possible. I would very much like to
build upon a foundation of the hard work of others, and minimise the need
to re-invent anything.




On Fri, 9 Nov 2018 at 19:02, Scharf, Michael <Michael.Scharf@hs-esslingen.de>
wrote:

> Todd,
>
>
>
> I suggest to have a look at ALTO and specifically at RFC 7971, which
> discusses such use cases.
>
>
>
> Please also have a look at the privacy implications of such information,
> which are mentioned therein.
>
>
>
> Michael
>
>
>
>
>
>
>
> *From:* Panrg [mailto:panrg-bounces@irtf.org] *On Behalf Of *Todd Hubers
> *Sent:* Friday, November 09, 2018 7:31 AM
> *To:* kojo=40cs.helsinki.fi@dmarc.ietf.org
> *Cc:* panrg@irtf.org; spencerdawkins.ietf@gmail.com
> *Subject:* Re: [PANRG] An earlier draft on signaling between network and
> end-hosts
>
>
>
> Hi Markku,
>
>
>
> I have a standard concept primarily focused on application-layer access to
> ISP broad contract information and status. However, I already flagged that
> may also benefit cross-layer collaboration. Please see attached. I'm trying
> to find collaborators to start an official draft. The draft document [
> https://tools.ietf.org/html/draft-sarolahti-tsvwg-crosslayer-01] is
> noteworthy.
>
>
>
> Will you be wanting to help? Are you aware of any other similar IETF
> documents?
>
>
>
> Thanks
>
>
>
> On Fri, 9 Nov 2018 at 12:32, Spencer Dawkins at IETF <
> spencerdawkins.ietf@gmail.com> wrote:
>
> Hi, Markku,
>
>
>
> On Thu, Nov 8, 2018 at 5:15 PM Markku Kojo <kojo=
> 40cs.helsinki.fi@dmarc.ietf.org> wrote:
>
> Hi, all
>
> in the panrg session yesterday I pointed out an older draft that Pasi,
> Sally and I initiated some 10+ years back:
>
> https://tools.ietf.org/html/draft-sarolahti-tsvwg-crosslayer-01
>
> Passing through the panrg email archieve after the meeting, I noticed that
> this draft as well as a few other useful docoments were already pointed
> out in the early days of the panrg list when the rg was about to be
> proposed (was not following the list at that time, sorry).
>
> Anyways, this draft started a discussion on existing mechanisms between
> the network and end-hosts and discusses also challenges with such
> mechanisms. Maybe still useful for panrg?
>
>
>
> Thanks for the reminder! I was vaguely following this research group when
> it was proposed, so probably noticed the discussion and then started doing
> telechat reviews and forgot everything except where my diet Pepsi was.
>
>
>
> Spencer
>
> _______________________________________________
> Panrg mailing list
> Panrg@irtf.org
> https://www.irtf.org/mailman/listinfo/panrg
>
>
>
>
> --
>
> --
>
> Todd Hubers
>


-- 
--
Todd Hubers