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

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 <
spencerdawkins.ietf@gmail.com> wrote:

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

-- 
--
Todd Hubers