> On Apr 17, 2023, at 21:09, Hesham ElBakoury via Starlink
> <[email protected]> wrote:
>
> From Saltzer perspective "The basis of the end-to-end principle is that the
> application knows best. If the application has the ability to tell an
> in-network service "Do X when you see my packets” that would seem to support
> the end-to-end principle."
That seems to imply some sort of active opt-in.... this is as far as I
can tell not how GEO PEPs or docsis ACK-thinning was introduced, instead the
network simply forced these things onto end-points/applications without even a
structured way to opt out, no?
> Other researchers have different prrspective and they think there is a need
> to for a new e2e principle.
What exactly is broken in the old one, requiring a fix?
>
> Hesham
>
>
> On Mon, Apr 17, 2023, 7:34 AM David P. Reed via Starlink
> <[email protected]> wrote:
> The idea that "special purpose" features should be interposed or added to the
> basic packet transport mechanisms continues to provoke people to suggest that
> it's time for the "end of" end-to-end arguments in the Internet.
>
> If one reads the initial paper, the reasons for NOT including "end to end
> functions" in the underlying transport are quite clearly laid out, and have
> nothing to do with any aspect of network technology that has changed in the
> last 50 years.
>
> So my answer is no.The primary sustaining reason is that the patterns of
> usage of the Internet continue to evolve, so building in ANY special, limited
> purpose functions beyond providing capacity and low latency into the packet
> and network transport interferes with evolvability. (unless you plan to throw
> out the entire infrastructure for every new application). This is pretty
> generally true, but I suppose if one is building one-time-use weaponry that
> blows itself up after a single standard use, evolvability doesn't matter.
>
> The one thing that remains the same is that those who sell gear for networks
> really want some kind of product differentiation beyond doing the things they
> are supposed to do, well. And they are great at inventing plausible
> sales-pitches. For example, Arista Networks has invented the need for
> massively overbuffered Ethernet switches, and so has added bufferbloat
> introduction to their sales pitch white papers. It's a cool feature to
> support massive queueing delay as a "throughput enhancement", I understand.
> I'm sure they can con(vince) a few customers that excessive buffering is good
> because, well, because they are a hot startup.
>
> The end-to-end argument doesn't say that putting really clever technology
> into switches, routers, or into a distributed system (adding "smarts" to the
> core functionality) is a bad idea. It says don't put functions that
> end-points (overlaid on the packet routing and transport) can implement quite
> well into the transport functionality.
>
> DNS lookup is a great example, actually. Why put it into satellite based
> routing and transport? It works fine, and it is currently ground based.
>
> Such
> _______________________________________________
> Starlink mailing list
> [email protected]
> https://lists.bufferbloat.net/listinfo/starlink
> _______________________________________________
> Starlink mailing list
> [email protected]
> https://lists.bufferbloat.net/listinfo/starlink
_______________________________________________
Starlink mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/starlink
