Endtoend arguments in system design Problem statement given

End-to-end arguments in system design Problem statement: given the freedom to implement a few functionalities in multiple “places” of the system (physical devices, or layers of protocols), where to implement them? Goal: correctness, completeness, and performance tradeoff Approach: end-to-end arguments CS 219/Fall 2002 10/07

What is end-to-end argument? • System: application, communication subsystem and the rest • End-to-end: – the function can completely and correctly be implemented ONLY with the knowledge and help of the application standing at the endpoints of the communication system. – Providing the function as a feature of the communication system is not feasible – appeals to application requirement – Move a function upward in a layered system closer to the application that uses the function CS 219/Fall 2002 10/07

Example: file transfer • Problem: transfer a file from host A to B • Steps: – At A, file system reads and passes the file to ftp – At A, ftp passes it to data comm. System – Packets of the file are transferred from A to B – At B, ftp retrieves the file – At B, file system writes the data to the disk CS 219/Fall 2002 10/07

Example (continued) • Threats: – Read error from the disk at A – Software errors in buffering and copying data by file system, ftp, or network, at A or B – Hardware errors at A or B – Transfer error in the network part – Host crashes at A or B CS 219/Fall 2002 10/07

Approach to handle threats • Approach 1: reinforce EVERY step – Using duplicate copies, timeout and retry, error detection, crash recovery, etc. – Maybe Not feasible – Uneconomical • Approach 2: end-to-end check and retry – Implement “end-to-end” error checking at Steps 1 and 5 – Retry if checking fails CS 219/Fall 2002 10/07

end-to-end approach in the example • Guarantee correctness and completeness of reliable file transfer • Reliability is the composite effects of all the components • Reliability in the network alone is not sufficient for end-to-end reliability • Application requirement is the key • Works if the error is not frequent CS 219/Fall 2002 10/07

End-to-end versus low-layer implementation • Correctness and completeness – Provided by end-to-end – Not by lower-layer implementations – Conclusion: end-to-end is a must • Performance perspective – End-to-end may suffer without lower-layer collaboration – Placing functions in lower layer is justified only if performance benefits outweighs the cost of additional complexity at the lower layer. • Redundancy perspective CS 219/Fall 2002 10/07

When to use the end-to-end approach • A functionality should be pushed to higher layers if possible, motivated by – – Correctness and completeness Reduced redundancy Incremental deployment More flexibility exposed to applications • Unless implementing it at lower layers can achieve large performance gains that outweigh the cost of additional complexity at lower layers CS 219/Fall 2002 10/07

More discussions and examples • End-to-end versus hop-by-hop reliability • Multicast: IP versus end-system – Case against IP multicast • Stateful multicast architecture: Requires IP routers to maintain group state • Vulnerable to flooding attack • Multicast address is needed for each group • Calls for infrastructure-level changes • Slow deployment • Implementing multicast congestion control at higher layers? – Case against end-system multicast • Performance penalty CS 219/Fall 2002 10/07

Another example: security • Security in a networking system • Bruce Schneier wrote in “Secrets and Lies: Digital security in a networked world” (John Wiley & Sons, Inc; 2000) – Cryptography is not the Answer. – Cryptography is not sufficient from the system perspective – “Security is a chain; it is only as secure as the weakest link” – “Security is a process, not a product” CS 219/Fall 2002 10/07

What has changed since then? • Operations in an untrustworthy world – Untrusted end-points (imply more mechanisms in the core to enforce good behaviors • More demanding applications – e. g. , streaming media (intermediate servers) • ISP service differentiation • The rise of third-party involvement • Less sophisticated users CS 219/Fall 2002 10/07

New Requirements • Security-related – Users communicate but do not totally trust each other – Anonymity in communications – End parties do not trust their software/hardware • The ends vs the middle – Third party involvement • Multiway communication • One party tries to force interaction on another CS 219/Fall 2002 10/07

Different forms of e 2 e arguments • network side – Avoid putting application-specific functions in the network – Push application-specific functions up and out to the edges • Application side – Decide where application-level services should be attached CS 219/Fall 2002 10/07

Network side: Modify the endnode • Placement of function at the edge may – compromise performance, but the functional objective is met – Represent an imperfect but acceptable solution – Not solve the problem CS 219/Fall 2002 10/07

Network side: the network core • Add functions to the network core – Enable more functionalities and applications – Prevent certain malicious applications • Design issues – Imposing a control element into the path of communication (e. g. by using the topology information/characteristics) – Revealing or hiding the message content (e. g. by using labels on information/keyword) CS 219/Fall 2002 10/07

Application side • Insert servers into the data path of an application – mail servers, anonymous message forwarders (e. g. nym) • Use of additional components away from the e 2 e design – Using trusted third party (e. g. via public key certificate) CS 219/Fall 2002 10/07

Some examples in wireless • Wireless proxy (I. e. , transcoding, web) – Handle end devices with different capabilities – Different client requirements – No change on the application server – Main complexity on the proxy • Wireless security • Reliability over the wireless link CS 219/Fall 2002 10/07