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

Hi Todd,

When writing RFC 7971 there was pretty strong consensus that at Internet scale no ALTO service could have *precise* information about what is listed below. Note that within a given domain (e.g., an AS) the situation can be different. As also mentioned already, there are not only technical challenges but also privacy issues that could prevent exposing certain information.

But, of course, other solutions can exist or be built in future. And they may not necessarily run into the same limitations.

Anyway, the lessons learnt for PANRG may be: If one tries to deal with path information that has been identified as a challenge for an ALTO service, it may make sense to ask what is different in another solution, and why it can overcome the limitations of ALTO.

Michael

From: Todd Hubers [mailto:todd.hubers@gmail.com]
Sent: Saturday, November 10, 2018 2:17 AM
To: Scharf, Michael
Cc: panrg@irtf.org; spencerdawkins.ietf@gmail.com
Subject: Re: [PANRG] An earlier draft on signaling between network and end-hosts

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<mailto: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<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<mailto:40cs.helsinki.fi@dmarc.ietf.org>
Cc: panrg@irtf.org<mailto:panrg@irtf.org>; spencerdawkins.ietf@gmail.com<mailto: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<mailto: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<mailto: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<mailto:Panrg@irtf.org>
https://www.irtf.org/mailman/listinfo/panrg

--
--
Todd Hubers

--
--
Todd Hubers