References on Layering and the Internet Architecture

• Application Layer Framing (ALF): D. Clark and D. Tennenhouse. Architectural Considerations for a New Generation of Protocols. In ACM SIGCOMM, 1990.
  "This paper identifies two new design principles, Application Level Framing and Integrated Layer Processing."

• PMTU: J. Mogul etal. Path MTU Discovery, RFC 1191, November 1990.
  (Followed by PMTU Black Hole Detect for paths where the ICMP packets are blocked on the reverse path.)

• Explicit Congestion Notification (ECN).
  The tranport explicitly advertises that it is ECN-capable, and the router in response gives an explicit congestion notification, instead of dropping the packet.

• E. Lear, Requirements for Discovering Middleboxes, April 2001.
  "The end to end nature of the Internet has been broken. Boxes within the middle of the network may change contents of packets at the Internet layer or above without the knowledge of the end devices. As these middleboxes such as NATs and firewalls have proliferated within the Internet, protocols are being developed to communicate with them. This document addresses requirements for discovery of those boxes."

• Transport's implicit assumptions of lower layers:
  • Packet losses:
    TCP assumes that packet losses are indications of congestion, but sometimes losses are from corruption on a wireles link.
    E.g., S. Dawkins et al, End-to-end Performance Implications of Links with Errors, RFC 3155, BCP, May 2001.
  • Reordered packets:
    TCP assumes that significantly reordered packets are indications of congestion. This is not always the case.
    E.g., S. Floyd, A Report on Some Recent Developments in TCP Congestion Control, IEEE Communications Magazine, April 2001.
  • Round-trip times:
    TCP measures round-trip times, and assumes that the lack of an acknowledgement within a certain period of time is a packet loss, and therefore an indication of congestion.
    E.g., the section on "TCP vs Link Layer Retransmission" in P. Karn et al., Advice for Internet Subnetwork Designers, RFC 3819, July 2004.
  • TCP congestion control implicitly assumes that all the packets in a flow are treated the same by the network, but this is not always the case.
  • M. Handley, On Inter-layer Assumptions (A view from the Transport Area), slides from a presentation at the IAB workshop on Wireless Internetworking, March 2000.
  • For other documents, see the PILC Working Group.

• Interactions of Link-Layer and Transport Protocols
  This is a web page maintained by Pasi Sarolahti with selected pointers to the literature.

• HTTP and TCP:
  The recent book on Web Protocols and Practice has a chapter on "HTTP/TCP Interaction". This includes discussions of aborted HTTP transfers, and the effects of TCP's Nagle's algorithm, delayed acknowledgements, and the TIME-WAIT state on HTTP.

• Layering applications over HTTP:
  K. Moore, On the use of HTTP as a Substrate, RFC 3205, February 2002.
  "The recent interest in layering new protocols over HTTP has raised a number of questions when such use is appropriate, and the proper way to use HTTP in contexts where it is appropriate."

• IP Tunnels and ECN/diffserv:
  
  • Older IP tunnels assumed that routers would not change any fields in the IP header. The advent of ECN and diffserv meant that this assumption was no longer valid.
    
  • S. Floyd et al., IPsec Interactions with ECN, draft-ietf-ipsec-ecn-02.txt, internet draft, December 1999.
    "The use of two bits in the IP header for ECN experimentation conflicts with header processing at IPsec tunnel endpoints in a manner that makes ECN unusable in the presence of IPsec tunnels. This document considers issues related to this conflict, describes two alternative solutions, and updates the IPsec architecture [RFC 2401] to include these alternatives."
  • D. Black, Differentiated Services and Tunnels, RFC 2983, October 2000.
    

• Transport and security:
  • Conflicts between transport and IPsec, web page from Yongguang Zhang.

• UPD and TCP as the New Waist:
  • J. Rosenberg, UDP and TCP as the New Waist of the Internet Hourglass, internet draft draft-rosenberg-internet-waist-hourglass, work in progress, 2008.

• IPsec and NATs:
  • B. Aboba, IPSEC-NAT Compatibility Requirements, RFC 3715, March 2004.
    "IPsec-NAT incompatibilities have become a major barrier to deployment of IPsec in one of its principal uses."

• Mobile IP and NATs:
  • O. Levkowetz et al, NAT Traversal for Mobile IP using UDP Tunnelling, draft-levkowetz-mobileip-nat-tunnel-00.txt, internet draft, work in progress, 2001.
    "MIP-NAT incompatibility issues have become a major barrier to deployment of Mobile IP in one of its principal uses. This draft describes a known incompatibility between NAT and Mobile IP, and also describes a possible solution."
  • S. Vaarala Mobile IP NAT/NAPT/Firewall Traversal, draft-vaarala-mobileip-nat-traversal-00.txt, internet draft, work in progress, 2001.
    "Mobile IP and Network Address Translation (NAT) are incompatible. This draft presents a mechanism of establishing a Mobile IP NAT traversal binding in a backwards compatible manner."

• IPsec and protection against misbehaving flows at routers:
  IPsec wants to hide headers, but when I am building mechanisms for routers to identify misbehaving flows that aren't doing end-to-end congestion control, I want to be able to identify which packets belong to which "flow". For a tunnel, the best that the router can do might be to assume that that tunnel corresponds to a single flow.
  
  • R. Mahajan et al., RED-PD: RED with Preferential Dropping, ICSI Tech Report TR-01-001, April 2001.

• Middleboxes and applications:
  Melinda Shore, Application Considerations for Midcom Middleboxes, draft-shore-midcom-apps-00.txt, work in progress, May 2001.
  "Anticipating some of the issues emanating from layer violation can help network designers build their networks to minimize complexity and help application and application protocol designers be more sensitive to the consequences of middlebox interactions."

• NATs:
  T. Hain, Architectural Implications of NAT, RFC 2993.
  "NATs break IPsec's authentication and encryption technologies because these technologies depend on an end-to-end consistency of the IP addresses in the IP headers, and therefore may stall further deployment of enhanced security across the Internet."

• Firewalls.

• "Transparent" (interception) proxies.

• L4-switches.

• DNS-overloading.

• Saltzer, Reed, and Clark, End-to-End Arguments in System Design, 1984.

• RJ Atkinson, March 23, 2001 email to the end2end-interest mailing list.
  "Folks are doing lots of micro-optimisations these days, at various points in the stack and in the end-to-end network system. While a given micro-optimisation might be worthwhile in a micro-network, many micro-optimisations are being deployed in a haphazard manner in the global Internet these days. The real result is a significantly less robust network for very little (if any) real measurable benefit."

• The NewArch project:
  
  • B. Braden et al., Developing a Next-Generation Internet Architecture, July 2000.
    "We believe that it is now time to revisit the Internet architecture."
    
  • Mark Handley, Role-based Architectures.

• Hans Kruse, The Pitfalls of Distributed Protocol Development: Unintentional Interactions between Network Operations and Applications Protocols, 8th International Conference on Telecommunication Systems Design, Nashville, March 2000.
  "Applications and application-level protocols such as end-to-end security and congestion control can interact in unexpected ways with network based functions such as proxies, address translators, packet filters, and nodes that perform traffic shaping and differentiated services functions. In this paper we reivew several recent examples ... and extract from these examples a sense of the basic protocol functions that cause potentially harmful interactions."

  "We suggest the following principles: 1. Avoid overloading of header fields... 2. Define header access rules... 3. Create a diagnostic feedback capability:"

• Tim Moors, A Critical Review of End-to-end Arguments in System Design, Proc. 2002 IEEE International Conference on Communications, pp. 1214-1219, April 2002.
  "The decision to implement reliable transfer in the transport layer is not justified on the basis of end-to-end arguments, but rather on the basis of trust.... We ... consider how local implementations may enhance performance, and then consider how they may degrade performance."
  In addition to correctness of function, the paper discusses end-to-end considerations relating to appropriate service, network transparency, ease of deployment, and decentralism. (And perhaps a later revision of the paper will improve on the discussion of end-to-end congestion control...)

• Bob Braden, Architectural Principles of the Internet, IPAM Tutorial, March 2002.
  "Network Architecture:
  * What entities are named, and how?
  * How do naming, addressing, and routing inter-relate?
  * Where & how is state installed and removed?
  * How are functions modularized?
  * How are resources allocated?
  * How are security boundaries drawn and enforced?"

• S. Dixit et al., Streamlining the Internet-Fiber Connection, IEEE Spectrum, April 20001.
  "Although much IP traffic is indeed carried over fibers with WDM, several intermediate technologies are required to make everything work [frame relay, ATM, SONET/SDH]. What needs to be determined is whether the services provided by these technologies can be supplied by a network architecture in which IP rides directly over WDM, and, if so, what that network might look like."

• Romanow, A., and Floyd, S., Dynamics of TCP Traffic over ATM Networks. IEEE JSAC, V. 13 N. 4, May 1995.
  "We introduce Early Packet Discard, a strategy that prevents fragmentation and brings throughput up to maximal levels by having the switch drop whole packets prior to buffer overflow."