Rule of thumb: when implementing a function or program, you should implement it at the end points.

Quote: End-to-end connectivity is a property of the Internet that allows all nodes of the network to send packets to all other nodes of the network, without requiring intermediate network elements to further interpret them.

One of my sources:

The way I think about it:

The end to end argument is a design principal that makes the programmers focus their programming end to end instead of on the communication network. This makes for more efficient programming as one only has to focus on the end 2 end hosts.

Worry about the end hosts when writing function or application of the layer your working on. So if your working on an application which is layer 7, then work on the server and client at layer 7 (there is no need to rewrite any of the lower layers as that is already handled, such by IP and TCP/UDP). If your working on writing a new Layer 3 protocol, then focus on Layer 3 at end to end (there is no need to worry about coding layer2 and layer 1 stuff). If your working on something that incorporates Layer 2 + Layer 3 (such as some SDN protocol; SDN blends layer2 and layer3 together) then worry about that end to end, there is no need to worry about Layer 1.

Somethings break the end to end argument but they are not necessarily bad.

Examples of End to End arguments:

  • encryption– the end hosts encrypt and decrypt. if the switches did that too, it would break end to end.
  • Transport layer(UDP, TCP, SCTP, etc..) – the transport layer is designed to provide end to end communication services. TCP for example is a reliable connection oriented transport service which provides end-to-end communication services.
  • duplicate packets
    • ignored at the receiving end by TCP, UDP not smart enough to detect (its responsibility of higher layer, the application to deal with duplicate packets with UDP)
  • packet retransmits
    • this happens at the ends hosts. the peers keep track of whats received and they ask for packets to be resent
  • client->server relationship between apps
    • When writing server, client apps, we dont need to write any code for layer4,3,2. We just use already implemented technology. There is no need to reinvent the wheel.
  • networked games
    • you program the server and the game, you dont need to worry about the network programming at the lower layers (you just need to decide if you want to use UDP or TCP or whatever)
    • sometimes you have to worry about the network, like setting up portforwards so that your client and server can communicate, but thats not your fault, and you didnt break the end2end argument, NAT broke that e2e argument, so you have to take the consequence).

Examples of breaking End to End arguments:

  • Caching
    • instead of guaranteeing data arrived from the end server, caching can provide the data from a closer peer
    • the data could be out of date, but then again a caching server should always make sure it has the latest data
    • lowers latency and increases speed of download of pages (espeically if bandwidth is greater to the caching server then to the end server)
  • NAT
    • NAT hides end to end host behind a middle Public address, thus breaking end to end.
    • NAT is implemented in the middle of the network archictecture and not at the end hosts of the communication stream, thus end to end is broken
    • in depth article on how it does that: 
    • The end-to-end arguments require that the core network should be stupid and its task is to forward message based on network layer information (source and destination IP address) of the package. Here, the intermediate device with NAT will not only forward the package. It will also make the translation of package on not only the network layer, but also the transport layer.
    • NAT breaks end to end, but its still very useful protocol

Does routing break end to end argument?

Answer here:

I think the answer is trying to say no, or end to end argument doesnt apply as its implemented by the Internet layer and according to RFC there is no guarantee of end-to-end deliveries.

Excerpt of highest ranked comment:

A router has a special job in that it must facilitate the end-to-end principle.

A router’s job, basically, is to interpret the destinatinaton IP address and determine the next router (or end node) to send it to. A router usually does two things:

Decrement the TTL

Find the next hop based on the destination IP address

It should not, in general, further interpret the packet.

Now, a NAT breaks end-to-end because it further interprets and transforms the packet. NAT might, for example, change the source address of the packet. In that case, you have broken end-to-end because another internet host will not be able to identify the specific host that sent the packet. They’ll only be able to identify the source address of the NAT.

More infoRFC 1812 makes this clear in section 2.2.1, where it describes the layering responsibilities:

  • Layer4 /Transport Layer The Transport Layer provides end-to-end communication services.
  • Layer4 / TCP is a reliable connection-oriented transport service that provides end-to-end reliability, resequencing, and flow control.
  • Layer3/ Internet Layer All Internet transport protocols use the Internet Protocol (IP) to carry data from source host to destination host. IP is a connectionless or datagram internetwork service, providing no end-to-end delivery guarantees. <– kossboss: i think this means the end to end argument simply doesnt apply to Internet Layer (so the question cant be answered; the question of whether or not end-to-end argument is broken at internet layer. such as when you divide by 0, are you at -inifnity, +inifnity or something undefined)

In section 2.2.3, it goes on to state that:

Routers provide datagram transport only, and they seek to minimize the state information necessary to sustain this service in the interest of routing flexibility and robustness.

A “normal” router doesn’t deal at all with the “end-to-end” principle. Its job is simply to deliver packets at the Internet layer, which is by definition “providing no end-to-end delivery guarantees”. That’s the Transport Layer’s job. NAT “breaks end-to-end” by operating at the Transport layer rather than simply the Internet layer, and keeping too much state about each connection.

Hope this makes sense. I know it can be confusing.

The end.


Leave a Reply

Your email address will not be published. Required fields are marked *