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

From: Markku Kojo <[email-masked]>
Date: Thu, 8 Nov 2018 12:14:48 +0200 (EET)

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?

BR,

/Markku

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 9 Nov 2018 08:32:55 +0700

Hi, Markku,

> 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

---

From: Todd Hubers <[email-masked]>
Date: Fri, 9 Nov 2018 17:30:31 +1100

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 <
[email-masked]> wrote:

> _______________________________________________
> Panrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/panrg
>

-- 
--
Todd Hubers

---

From: "Scharf, Michael" <[email-masked]>
Date: Fri, 9 Nov 2018 08:02:32 +0000

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:[email-masked]] On Behalf Of Todd Hubers
Sent: Friday, November 09, 2018 7:31 AM
To: kojo=[email-masked]
Cc: [email-masked]; [email-masked]
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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Markku,

On Thu, Nov 8, 2018 at 5:15 PM Markku Kojo <kojo=[email-masked]<mailto:[email-masked]>> wrote:
Hi, all

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
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/panrg

--
--
Todd Hubers

---

From: Todd Hubers <[email-masked]>
Date: Sat, 10 Nov 2018 12:16:40 +1100

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 <[email-masked]>
wrote:

> *From:* Panrg [mailto:[email-masked]] *On Behalf Of *Todd Hubers
> *Sent:* Friday, November 09, 2018 7:31 AM
> *To:* kojo=[email-masked]
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [PANRG] An earlier draft on signaling between network and
> end-hosts
>
>
>
> Hi Markku,
>
>
>

-- 
--
Todd Hubers

---

From: "Scharf, Michael" <[email-masked]>
Date: Sat, 10 Nov 2018 07:25:14 +0000

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:[email-masked]]
Sent: Saturday, November 10, 2018 2:17 AM
To: Scharf, Michael
Cc: [email-masked]; [email-masked]
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 <[email-masked]<mailto:[email-masked]>> wrote:
Todd,

Michael

From: Panrg [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Todd Hubers
Sent: Friday, November 09, 2018 7:31 AM
To: kojo=[email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [PANRG] An earlier draft on signaling between network and end-hosts

Hi Markku,

Thanks

Spencer

--
--
Todd Hubers

--
--
Todd Hubers

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 12 Nov 2018 17:18:52 -0600

Hi, Todd,

> lists problems that presumably a multi-layer solution would be fixing.

Yes, I'd agree, and appreciate you sending the pointer.

Mirja is (IIRC) the AD for ALTO now, but I had ALTO for a couple of years
after joining the IESG, and this list was very much the result of looking
at everything the ALTO working group wished they'd been able to know in
order to select "best initial peers". Their use case is pretty different
these days, but I don't think the list of what they wish they could know
has changed very much at all.

Somewhere between draft-irtf-panrg-what-not-to-do and solutions drafts
(whether in IRTF or IETF), figuring out what has changed so  that obstacles
to deployment aren't obstacles turns out to be really important.

Spencer

>> *      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).***
> On Fri, 9 Nov 2018 at 19:02, Scharf, Michael <
> [email-masked]> wrote:
>
>> Todd,
>>
>>
>>
>> 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.
>>
>>
>>

---

From: Todd Hubers <[email-masked]>
Date: Tue, 13 Nov 2018 10:54:20 +1100

Hi Spencer,

I was planning to work primarily with NMRG when I complete the initial
draft. I have started a GIT repo, and some mock code. I'm a software and a
network engineer. I would love to have standards and code developed side by
side.

I think the whole domain that I'm looking at will prove to be quite
interesting to tease out. Standardisation of a range of solution options is
certainly important, but I will be excited to venture into the unknowns of
new engineering, by focusing to remove remaining obstacles.

Regards,

Todd.

On Tue, 13 Nov 2018 at 10:19, Spencer Dawkins at IETF <
[email-masked]> wrote:

>> 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.
>>
>
>> 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.
>>
>>
>>
>>
>>> *Subject:* Re: [PANRG] An earlier draft on signaling between network
>>> and end-hosts
>>>
>>>
>>>
>>> Hi Markku,
>>>
>>>
>>>
>>> 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
>>>

-- 
--
Todd Hubers