Re: What is the long term plan for Internet evolution?

Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 30 June 2021 03:07 UTC

Subject: Re: What is the long term plan for Internet evolution?
To: Kent Watsen <kent@watsen.net>, Michael Richardson <mcr+ietf@sandelman.ca>
Cc: Phillip Hallam-Baker <phill@hallambaker.com>, IETF Discussion Mailing List <ietf@ietf.org>
References: <CAMm+LwiFajxuV3E_u7b-f=7DqTHXG_4Y=VLoCsUxknD_mCp1=Q@mail.gmail.com> <00722e06-a385-251c-d95d-2ff67e83f5c1@foobar.org> <CAMm+LwgwwX4zhqqH27FtBEyKRn74BdunswpembR_O6R34vTuSA@mail.gmail.com> <16008.1625010713@localhost> <0100017a5a6c13e7-53cfcee8-b8dd-45b1-9a26-f30f497db3a9-000000@email.amazonses.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <96a11f31-1126-7aba-5f26-3d33a432b345@gmail.com>
Date: Wed, 30 Jun 2021 15:07:37 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <0100017a5a6c13e7-53cfcee8-b8dd-45b1-9a26-f30f497db3a9-000000@email.amazonses.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/4Iic4SncZLyS0AeDaGp0zKyNol8>
Precedence: list

GRASP does this too. Actually, there isn't even a S:Ack needed. There is a timeout for non-response, however.

Regards
   Brian

On 30-Jun-21 12:57, Kent Watsen wrote:
> NETCONF Subscribed Notifications (RFC 8639) over HTTP/2 also does this.
> 
> K.
> 
> 
>> On Jun 29, 2021, at 7:51 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
>>
>>
>> Phillip Hallam-Baker <phill@hallambaker.com> wrote:
>>> That is what a transaction is, right. Nope. Many of my transactions have
>>> people in the middle of them making decisions or big compute loads. So in
>>> the HTTP world we end up with
>>
>>> < C:Request, S:Ack, [C:Poll, S:Pending,] * C:Poll, S: Response>
>>
>>> That is plain ugly. The pattern I really want is:
>>
>>> < C:Request, S:Ack, S: Response>
>>
>>> There is no need to poll, just respond when finished. That might be
>>> seconds, minutes, days or even years.
>>
>> CoAP supports this.
>>
>>> For telemetry, the pattern I want is
>>
>>> < C:Config, S:Data, S:Data, S:Data, S:Data, S:Data, C:Config, S:Data,
>>> S:Data, ...>
>>
>>> Again, this just doesn't fit onto the TCP or HTTP communication patterns
>>> and it is not really something QUIC is designed for. Sure we could make do.
>>> But I choose not to.
>>
>> CoAP Observe does this.
>> CoAP works better without NAT because the NAT closes the subsequent S:Data in
>> many cases.
>>
>> --
>> Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
>>           Sandelman Software Works Inc, Ottawa and Worldwide
>>
>>
>>
>>
>

What is the long term plan for Internet evolution? Phillip Hallam-Baker
Re: What is the long term plan for Internet evolu… Nick Hilliard
Re: What is the long term plan for Internet evolu… Phillip Hallam-Baker
Re: What is the long term plan for Internet evolu… Brian E Carpenter
RE: What is the long term plan for Internet evolu… Larry Masinter
Re: What is the long term plan for Internet evolu… Benjamin Kaduk
Re: What is the long term plan for Internet evolu… Michael Richardson
Re: What is the long term plan for Internet evolu… Kent Watsen
Re: What is the long term plan for Internet evolu… Phillip Hallam-Baker
Re: What is the long term plan for Internet evolu… Brian E Carpenter
Re: What is the long term plan for Internet evolu… Behcet Sarikaya