1.End-to-End Arguments in System Design

• end-to-end argument def: functions at low levels may be redundant when compared to the cost of providing them at that low level
• authors suggest moving functions upward in a layered system
• possible problems for end-to-end transmission: hardware faults, software mistakes in buffering and copying, processor or memory transient errors, packet drops or duplicates
• e.g. file transfer program: A->B, B calculates checksum of the original and sends it back to A
• communications level proposal of file transfer to achieve a reliable data transmissions: selective redundancy in packet checksums, sequence number checking, internal retry mechanisms
• authors suggest that the comm level proposals has "no effect on inevitability or correctness of the outcome", and that the file transfer program must supply the reliability guarantee itself
• e.g. app programmers know there's a packet checksum on the gateways so they didn't include any checksums in the program level. A bite pair interchange occurred in one gateway, which happens every million bytes. Files were corrupted and manual comparison has to be made.
• performance aspects: authors suggest that the lower levels need not provide prefect reliability since app level has to do it anyways, and that it's probably not important to strive for a negligible error rate at any point below the app level. If error-checksum related functions were performed in network comm level, 1) those apps that don't need them will pay for it, 2) low-level may not have enough info and cannot do the job efficiently
• **thoughts**: detect bit-error rate in the communications level and decides if there's any need for checksum?
• delivery guarantees: low level may be wasting its effort providing a function that the app level will implement anyways (ARPANET example: knowing for sure that the msg was delivered to the target isn't very important)
  
• secure transmission: 1) low level encryption/decryption must be trusted to manage the keys, 2) data will be in the clear and vulnerable, 3) authenticity must still be checked by the app. Encryption in low levels may be called for if necessary.
• **thoughts**: so why not call for the checksums in communications layer when it is needed? leave the decision to the application designer
• duplicate message suppression: app level duplicates look different to comm system, so it cannot suppress them
• guaranteeing FIFO message delivery: an independent mechanism at a higher level must control the ordering of actions
• transaction management: applying end-to-end argument to SWALLOW distributed data storage system. Low-level does not suppress duplicate messages since 1) object identifier and version info suffices to detect duplicates, 2) effect of a duplicate read request is only to generate a duplicate response, which is easily discarded. Thus, data comm protocol is significantly simplified.
• Identifying the ends: live voice chat, live video streams: mild packet loss is acceptible, low-level checksum isn't important; voicemail: short delays are ok, so low-level reliability measures is okay.
• **thoughts**: so why not call for the checksums in communications layer when it is needed? leave the decision to the application designer
• Conclusions from the authors: awareness of end-to-end argements can help program designers not to be tempted to write more functions than necessary. end-to-end argument will help to add substance about proper layering of communication protocols.