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

Hi, Todd,

On Fri, Nov 9, 2018 at 7:16 PM Todd Hubers <todd.hubers@gmail.com> wrote:

> 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.
>

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

>  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
>