Breaking Up the Transport Logjam Bryan Ford Janardhan Iyengar Max - PowerPoint PPT Presentation

Breaking Up the Transport Logjam Bryan Ford Janardhan Iyengar Max Planck Institute Franklin & Marshall for Software Systems College and Yale University jiyengar@fandm.edu baford@mpi-sws.org TSVAREA Open Meeting, IETF 73, 19 November 2008

Evolutionary Pressures on Transports ● Applications need more fexible abstractions — many semantic variations [RDP, DCCP, SCTP, SST, ...] ● Networks need new congestion control schemes — high-speed [Floyd03], wireless links [Lochert07], ... ● Users need better use of available bandwidth — dispersion [Gustafsson97], multihoming [SCTP], logistics [Swany05], concurrent multipath [Iyengar06]… ● Operators need administrative control — Performance Enhancing Proxies [RFC3135], NATs and Firewalls [RFC3022], traffc shapers

The Transport Layer is Stuck in an Evolutionary Logjam!

Many Solutions, None Cleanly Deployable ● New transports undeployable — NATs & frewalls — chicken & egg: application demand vs kernel support ● New congestion control schemes undeployable — impassable “TCP-friendliness” barrier — must work end-to-end, on all network types in path ● Multipath/multifow enhancements undeployable — “You want how many fows? Not on my network!” — Fundamentally “TCP-unfriendly”?

The Problem Traditional transports confate 3 function areas ... Semantics, Reliability Concerns ( applications care) Transport Abstraction Performance Concerns Transport Congestion ( users, opers care) Protocol Control Endpoint Identification (port numbers) Naming, Routing Concerns ( NATs, firewalls care) T o break transport logjam, must separate concerns

Our Proposal Break up the Transport according to these functions: Application Layer Application Layer Presentation Layer Presentation Layer Session Layer Session Layer Transport Layer Transport Layer Flow Regulation Layer Network Layer Endpoint Layer Data Link Layer Network Layer Physical Layer Data Link Layer Physical Layer

Endpoint Layer

Endpoint Identifcation via Ports Current transports have separate port spaces TCP DCCP Port Space Port Space UDP Port Space TCP Header DCCP Header UDP Header Source Dest Source Dest Source Dest Port Port Port Port Port Port Network Layer IP Header IP Address Space Source IP Address Dest IP Address

But What Are Ports? Ports are routing info ! — IP address ⇒ Inter-Host Routing — port numbers ⇒ Intra- Host Routing Do ports really belong in the Network Layer? ● Firewalls, NATs, traffc shapers need to know ports — Parse transport headers ⇒ only TCP, UDP get through ● IPv4: ports increasingly just “16 more IP address bits” — DHCP port borrowing/sharing [Despres, Bajko, Boucadair] ● IPv6: could dispense with ports entirely — Assign each host a CIDR subnet, low bits = “port #”

A Pragmatic Approach Factor endpoints into shared Endpoint Layer Transport Header Transport Header Endpoint Layer Port Space Endpoint Header Source Dest Port Port Network Layer IP Header IP Address Space Source IP Address Dest IP Address

Surprise! Workable starting point exists — UDP ! Transport Header Transport Header Endpoint Layer Port Space UDP Header Source Dest Port Port Network Layer IP Header IP Address Space Source IP Address Dest IP Address

Embrace the Inevitable It's happening in any case! ● TCP/UDP is “New Waist of the Internet Hourglass” [Rosenberg 08] ● Every new transport requires UDP encapsulations — SCTP [Ong 00, Tuexen 07, Denis-Courmont 08] — DCCP [Phelan 08] ● And a lot of non-transports do too — IPSEC [RFC 3947/3948], Mobile IP [RFC 3519], Teredo [RFC 4380], … ...but the new model also has technical benefts ...

Practical Benefts Can now evolve separately: ● Transport functions: — New transports get through frewalls, NATs, etc. — Easily deploy new user-space transports, interoperable with kernel transports — Application controls negotiation among transports ● Endpoint functions: — Better cooperation with NATs [UPnP, NAT -PMP, ...] — identity/locator split, port/service names [Touch06], security and authentication info ...?

Kernel/User Transport Non- Interoperability User-space transports are easy to deploy, but can't talk to kernel implementations of same transport! (without special privileges, raw sockets, etc.) Host A Host B Application Application User User User-space Transport Kernel-space Kernel Transport UDP Kernel Network Protocol Network Protocol

Kernel/User Transport Interoperability Endpoint layer provides full interoperability , user-space transports require no special privileges Host A Host B Application Application User User User-space Transport Kernel-space Transport Kernel Endpoint Protocol Endpoint Protocol Kernel Network Protocol Network Protocol

Transport Negotiation Many applications support multiple transports , but can't negotiate them effciently “Cautious Negotiation” “Shotgun Negotiation” Host A Host B Host A Host B TCP TCP “TCP or UDP?” “Hello?” UDP “Hello?” “Hello?” “UDP!” UDP “Hello!” UDP “Hello!” TCP RST

“Zero-RTT” Transport Negotiation When application controls its Endpoint Layer ports, it can combine transport negotiation with setup Host A Host B T1 SYN T3 SYN T2 SYN Transport Negotiation “Meta-SYN” B chooses Transport 2 T2 SYN/ACK

Future Endpoint Layer Evolution “Next-Generation Endpoint Layer” could: ● Remain backward-compatible with UDP — Use same port space, fall back on UDP transparently ● Annotate endpoints with richer information — Port names [Touch 06], user/service names, auth info, ...? ● Proactively advertise listen sockets [Cheshire?] — NATs could propagate listener advertisements upstream, translate inbound connections as policy permits — Enable cleaner solutions to “NAT signaling” mess? [UPnP, NAT -PMP, MIDCOM, NSIS, ...]

Flow Layer

Traditional “Flow Regulation” Transport includes end-to-end congestion control — regulates fow transmission rate to network capacity But one E2E path may cross many ... — different network technologies ● Wired LAN, WAN, WiFi, Cellular, AdHoc, Satellite, … ● Each needs different, specialized CC algorithms! — different administrative domains ● Each cares about CC algorithm in use! Can't tune performance, fairness in one domain w/o affecting other domains, E2E semantics [RFC3515]

Proposed Solution Factor fow regulation into underlying Flow Layer Transport Layer Transport Semantics , Reliability Flow Layer Flow Performance Regulation Endpoint Layer Endpoint Naming Network Layer

Practical Benefts (1/3) Can split E2E fow into separate CC segments — Specialize CC algorithm to network technology — Specialize CC algorithm within admin domain … without interfering with E2E transport semantics ! Segment 1 Segment 2 Segment 3 Application WiFi LAN Satellite Internet Core Application Transport Transport Flow Flow Flow Flow Endpoint Endpoint Endpoint Endpoint Network Network Network Network Host A Flow Middlebox Flow Middlebox Host B

Example Scenarios (1) Last-mile proxies for wireless/mobile links Mobility-Aware Ad Hoc Wireless Congestion Control TCP-friendly Congestion Control Congestion Control [M-TCP, ELFN, ...] [Reno, TFRC, ...] [WTCP, ATCP, ...] Flow Flow Host Host MidB MidB Mobile Ad Hoc Wired Wireless Wireless Internet Link Network

Example Scenarios (2) Lossy Satellite or Long-Distance Wireless Links Specialized/High-Performance CC TCP-friendly CC TCP-friendly CC [HS-TCP, Scalable TCP, BIC-TCP, ...] [Reno, TFRC, ...] [Reno, TFRC, ...] Flow Flow Host Host MidB MidB LAN LAN Flow Flow Host Host MidB MidB LAN LAN

Example Scenarios (3) Inter-Site WAN Links in Corporate Networks TCP-friendly or TCP-friendly or Locally Configured Explicit Congestion Control Locally Configured Congestion Control [XCP, manually configured max rate, ...] Congestion Control Flow Flow Host Host MidB MidB Site 1 LAN Reserved Bandwidth Site 2 LAN WAN Link

End-to-End Congestion Control, One Segment at a Time Transmit Congestion Control Loop 1 Congestion Control Loop 2 Receive Buffer Buffer (6) “Packets “Packets (6) (7) “Slow “Slow (4) “Slow “Slow (3) “Packets “Packets (7) (4) (3) App App Dropped!” Dropped!” Down!” Down!” Dropped!” Down!” Down!” Dropped!” Feedback Feedback (ACKs, etc.) (ACKs, etc.) (5) Queue Queue (5) (2) Queue Queue (2) Fills Fills Fills Fills Net Net Source Router Flow Router Target Router Router Host Middlebox Host (1) Link Link (1) Bottleneck Bottleneck

Practical Benefts (2/3) Incrementally deploy performance enhancements — multihoming [RFC 4960], multipath [Lee 01], dispersion [Gustafsson 97], aggregation [Seshan 97], ... … without affecting E2E transport semantics! end-to-end multipath Application Protocol Application Protocol Transport Protocol Transport Protocol Flow Protocol Flow Protocol Flow Protocol Flow Protocol Endpoint Protocol Endpoint Protocol Endpoint Protocol Endpoint Protocol Host A Flow Middlebox Flow Middlebox Host B per-segment multipath