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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thank you Philip for starting this discussion.
I think we should definitely discuss this.

The issue I wish to add is the upcoming LEO satellite networks like Star Link, OneWeb, and others.

Behcet

On Tue, Jun 29, 2021 at 9:14 PM Phillip Hallam-Baker <phill@xxxxxxxxxxxxxxx> wrote:
And I am sure this has been re-invented multiple times over.

On Tue, Jun 29, 2021 at 8:57 PM Kent Watsen <kent@xxxxxxxxxx> 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@xxxxxxxxxxxx> wrote:
>
>
> Phillip Hallam-Baker <phill@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxx>   . o O ( IPv6 IøT consulting )
>           Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux