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

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

[David P. Reed]

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


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

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

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

[Hesham ElBakoury]

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

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

[Sebastian Moeller]

> On Apr 17, 2023, at 21:09, Hesham ElBakoury via Starlink <starlink@lists.bufferbloat.net> 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 <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
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink