Re: [Starlink] IXPs in space, and the end-to-end argument

[Hesham ElBakoury <helbakoury@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2910 bytes --]

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

Other researchers have different prrspective and they think there is a need
to for a new e2e principle.

Hesham


On Mon, Apr 17, 2023, 7:34 AM David P. Reed via Starlink <
starlink@lists.bufferbloat.net> 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
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>

[-- Attachment #2: Type: text/html, Size: 4352 bytes --]