breaking up the transport logjam · breaking up the transport logjam bryan ford max planck...

29
Breaking Up the Transport Logjam Bryan Ford Max Planck Institute for Software Systems [email protected] Janardhan Iyengar Franklin & Marshall College [email protected] HotNets-VII, October 6-7, 2008

Upload: others

Post on 30-Jun-2020

0 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Breaking Up the Transport Logjam · Breaking Up the Transport Logjam Bryan Ford Max Planck Institute for Software Systems baford@mpi-sws.org Janardhan Iyengar Franklin & Marshall

Breaking Up the Transport Logjam

Bryan FordMax Planck Institutefor Software Systems

[email protected]

Janardhan IyengarFranklin & Marshall

College

[email protected]

HotNets-VII, October 6-7, 2008

Page 2: Breaking Up the Transport Logjam · Breaking Up the Transport Logjam Bryan Ford Max Planck Institute for Software Systems baford@mpi-sws.org Janardhan Iyengar Franklin & Marshall

Evolutionary Pressures on Transports● Applications need more fexible abstractions

— better datagrams [DCCP], streams [SCTP, Ford07]

● 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

● We have partial solutions, but no deployment

Page 3: Breaking Up the Transport Logjam · Breaking Up the Transport Logjam Bryan Ford Max Planck Institute for Software Systems baford@mpi-sws.org Janardhan Iyengar Franklin & Marshall

Many solutions, None deployable

● New transports undeployable— NATs & frewalls— which comes frst: App-demand or OS 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!”— TCP-unfriendly?

Page 4: Breaking Up the Transport Logjam · Breaking Up the Transport Logjam Bryan Ford Max Planck Institute for Software Systems baford@mpi-sws.org Janardhan Iyengar Franklin & Marshall

The Transport Layer isStuck in an Evolutionary Logjam!

Page 5: Breaking Up the Transport Logjam · Breaking Up the Transport Logjam Bryan Ford Max Planck Institute for Software Systems baford@mpi-sws.org Janardhan Iyengar Franklin & Marshall

The Problem

Traditional transports confate 3 function areas...

To break transport logjam, must separate concerns

TransportProtocol

Endpoint Identification (port numbers)

Transport Abstraction

CongestionControl

Semantics, Reliability Concerns(applications care)

PerformanceConcerns

(users, opers care)

Naming, Routing Concerns(NATs, firewalls care)

Page 6: Breaking Up the Transport Logjam · Breaking Up the Transport Logjam Bryan Ford Max Planck Institute for Software Systems baford@mpi-sws.org Janardhan Iyengar Franklin & Marshall

Our Proposal

Physical Layer

Data Link Layer

Network Layer

Session Layer

Application Layer

Presentation Layer

Physical Layer

Data Link Layer

Network Layer

Session Layer

Application Layer

Presentation Layer

Endpoint Layer

Flow Regulation Layer

Transport Layer

Transport Layer

Break up the Transport according to these functions:

Page 7: Breaking Up the Transport Logjam · Breaking Up the Transport Logjam Bryan Ford Max Planck Institute for Software Systems baford@mpi-sws.org Janardhan Iyengar Franklin & Marshall

Endpoint Layer

Page 8: Breaking Up the Transport Logjam · Breaking Up the Transport Logjam Bryan Ford Max Planck Institute for Software Systems baford@mpi-sws.org Janardhan Iyengar Franklin & Marshall

TCP HeaderUDP Header DCCP Header

Endpoint Identifcation via Ports

Current transports have separate port spaces

IP Header

SourcePort

DestPort

SourcePort

DestPort

SourcePort

DestPort

Source IP AddressDest IP Address

TCPPort Space

UDPPort Space

DCCPPort Space

Network LayerIP Address Space

Page 9: Breaking Up the Transport Logjam · Breaking Up the Transport Logjam Bryan Ford Max Planck Institute for Software Systems baford@mpi-sws.org Janardhan Iyengar Franklin & Marshall

But What Are Ports?

● Ports are really routing info!— IP address ⇒ Inter-Host Routing

— port numbers ⇒ Intra-Host Routing

● … should have been part of Network Layer?

● NATs/Firewalls treat ports as routing info!— Care about application endpoints, not just hosts— Therefore, must understand transport headers

● Result: Only TCP, UDP can get through

Page 10: Breaking Up the Transport Logjam · Breaking Up the Transport Logjam Bryan Ford Max Planck Institute for Software Systems baford@mpi-sws.org Janardhan Iyengar Franklin & Marshall

Proposed Solution

Factor endpoint info into uniform Endpoint Layer

Transport HeaderTransport Header

IP Header

Source IP AddressDest IP Address

Endpoint LayerPort Space

Network LayerIP Address Space

Endpoint Header

SourcePort

DestPort

Page 11: Breaking Up the Transport Logjam · Breaking Up the Transport Logjam Bryan Ford Max Planck Institute for Software Systems baford@mpi-sws.org Janardhan Iyengar Franklin & Marshall

Surprise!

Workable starting point exists — UDP!

Transport HeaderTransport Header

IP Header

Source IP AddressDest IP Address

Endpoint LayerPort Space

Network LayerIP Address Space

UDP Header

SourcePort

DestPort

Page 12: Breaking Up the Transport Logjam · Breaking Up the Transport Logjam Bryan Ford Max Planck Institute for Software Systems baford@mpi-sws.org Janardhan Iyengar Franklin & Marshall

Practical Benefts

Can now evolve separately:● Transport functions:

— New transports get through NATs, frewalls— 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 ...?

Page 13: Breaking Up the Transport Logjam · Breaking Up the Transport Logjam Bryan Ford Max Planck Institute for Software Systems baford@mpi-sws.org Janardhan Iyengar Franklin & Marshall

Flow Layer

Page 14: Breaking Up the Transport Logjam · Breaking Up the Transport Logjam Bryan Ford Max Planck Institute for Software Systems baford@mpi-sws.org Janardhan Iyengar Franklin & Marshall

Traditional “Flow Regulation”

Transport includes end-to-end congestion control— to regulate fow transmission rate

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!

Page 15: Breaking Up the Transport Logjam · Breaking Up the Transport Logjam Bryan Ford Max Planck Institute for Software Systems baford@mpi-sws.org Janardhan Iyengar Franklin & Marshall

Proposed Solution

Factor fow regulation into underlying Flow Layer

Transport Layer

Network Layer

Endpoint Layer

Flow Layer

Transport Semantics, Reliability

Flow Performance Regulation

Endpoint Naming

Page 16: Breaking Up the Transport Logjam · Breaking Up the Transport Logjam Bryan Ford Max Planck Institute for Software Systems baford@mpi-sws.org Janardhan Iyengar Franklin & Marshall

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!

Endpoint

Flow

Host A Host B

Network

Transport

Application

Endpoint

Flow

Network

Transport

Application

Endpoint

Flow

Network

Endpoint

Flow

Network

Flow Middlebox Flow Middlebox

Segment 2Satellite

Segment 1WiFi LAN

Segment 3Internet Core

Page 17: Breaking Up the Transport Logjam · Breaking Up the Transport Logjam Bryan Ford Max Planck Institute for Software Systems baford@mpi-sws.org Janardhan Iyengar Franklin & Marshall

Practical Benefts (2/3)

Incrementally deploy performance enhancements— multihoming, multipath, dispersion, aggregation...

… without affecting E2E transport semantics!

Endpoint Protocol

Host A Host B

Transport Protocol

Application Protocol

Endpoint Protocol

Transport Protocol

Application Protocol

Endpoint Protocol

Flow Middlebox

end-to-end multipath

Endpoint Protocol

Flow Protocol Flow ProtocolFlow Protocol Flow Protocol

per-segment multipath

Flow Middlebox

Page 18: Breaking Up the Transport Logjam · Breaking Up the Transport Logjam Bryan Ford Max Planck Institute for Software Systems baford@mpi-sws.org Janardhan Iyengar Franklin & Marshall

Practical Benefts (3/3)

Endpoint Protocol

Host A2

Transport Protocol

Application ProtocolEndpoint Protocol

Flow Middlebox

Endpoint Protocol

Flow Protocol

Flow Protocol Flow Protocol

Flow Middlebox

Endpoint Protocol

Host A1

Transport Protocol

Application Protocol

Flow Protocol

Endpoint Protocol

Host B2

Transport Protocol

Application Protocol

Flow Protocol

Endpoint Protocol

Host B1

Transport Protocol

Application Protocol

Flow Protocol

AggregateFlow

Shared Access Networkor Wide-Area Link

● Can aggregate fows cleanly within domains for— Effcient traffc measurement, management— Fairness at “macro-fow” granularity

Page 19: Breaking Up the Transport Logjam · Breaking Up the Transport Logjam Bryan Ford Max Planck Institute for Software Systems baford@mpi-sws.org Janardhan Iyengar Franklin & Marshall

Developing the Flow Layer

● Two likely “starting points” already exist:— Congestion Manager [Balakrishnan99]— DCCP [Kohler06]

(just stop thinking of it as a “transport”)

● Major work areas:— Support for fow middleboxes, path segmenting— Interfaces between (new) higher & lower layers

Page 20: Breaking Up the Transport Logjam · Breaking Up the Transport Logjam Bryan Ford Max Planck Institute for Software Systems baford@mpi-sws.org Janardhan Iyengar Franklin & Marshall

Transport Layer

Page 21: Breaking Up the Transport Logjam · Breaking Up the Transport Logjam Bryan Ford Max Planck Institute for Software Systems baford@mpi-sws.org Janardhan Iyengar Franklin & Marshall

Transport Layer

Contains “what's left”:● Semantic abstractions that apps care about

— Datagrams, streams, multi-streams, …

● Reliability mechanisms— “Hard” acknowledgment, retransmission

● App-driven buffer/performance control— Receiver-directed fow control— Stream prioritization— ...

Page 22: Breaking Up the Transport Logjam · Breaking Up the Transport Logjam Bryan Ford Max Planck Institute for Software Systems baford@mpi-sws.org Janardhan Iyengar Franklin & Marshall

Breaking Up the Transport Logjam

● New transports undeployable— Can traverse NATs & frewalls— Can deploy in kernels or applications

● New congestion control schemes undeployable— Can specialize to different network types— Can deploy/manage within administrative domains

● Multipath/multifow enhancements undeployable— Can deploy/manage within administrative domains

Page 23: Breaking Up the Transport Logjam · Breaking Up the Transport Logjam Bryan Ford Max Planck Institute for Software Systems baford@mpi-sws.org Janardhan Iyengar Franklin & Marshall

Only the Beginning...Promising architecture (we think), butlots of details to work out

— Functionality within each layer— Interfaces between each layer— Application-visible API changes

Big, open-ended design space— We are starting to explore, but

would love to collaborate with others! — If you know of spaces where you could use this

framework, we'd love to know!

Page 24: Breaking Up the Transport Logjam · Breaking Up the Transport Logjam Bryan Ford Max Planck Institute for Software Systems baford@mpi-sws.org Janardhan Iyengar Franklin & Marshall

Conclusion

● Transport evolution is stuck

● To unstick, need to separate:— Endpoint naming/routing into separate Endpoint Layer— Flow regulation into separate Flow Layer

● Leave semantic abstractions in Transport Layer

Page 25: Breaking Up the Transport Logjam · Breaking Up the Transport Logjam Bryan Ford Max Planck Institute for Software Systems baford@mpi-sws.org Janardhan Iyengar Franklin & Marshall

Complexity

● More layers => increase

● Puts necessary hacks into framework => decrease

● What's the balance?

Page 26: Breaking Up the Transport Logjam · Breaking Up the Transport Logjam Bryan Ford Max Planck Institute for Software Systems baford@mpi-sws.org Janardhan Iyengar Franklin & Marshall

What about the e2e principle?

● Flow layer implements in-network mechanisms that focus on communication performance— Precisely the role for which the e2e principle

justifes in-network mechanisms

● All state in the fow middleboxes is performance-related soft state

● Transport layer retains state related to reliability— End-to-end fate-sharing is thus preserved

● Transport layer is still the frst end-to-end layer

Page 27: Breaking Up the Transport Logjam · Breaking Up the Transport Logjam Bryan Ford Max Planck Institute for Software Systems baford@mpi-sws.org Janardhan Iyengar Franklin & Marshall

Kernel/User Transport Interoperation

Network Protocol

Kernel-spaceTransport

Application

Network Protocol

User-spaceTransport

UDP

Application

Ker

nel

Use

r

Ker

nel

Use

r

Host A Host B

Page 28: Breaking Up the Transport Logjam · Breaking Up the Transport Logjam Bryan Ford Max Planck Institute for Software Systems baford@mpi-sws.org Janardhan Iyengar Franklin & Marshall

Kernel/User Transport Interoperation

Network Protocol

Kernel-spaceTransport

Application

Network Protocol

User-spaceTransport

Application

Ke

rne

lU

ser

Ke

rne

lU

ser

Endpoint ProtocolEndpoint Protocol

Host A Host B

Page 29: Breaking Up the Transport Logjam · Breaking Up the Transport Logjam Bryan Ford Max Planck Institute for Software Systems baford@mpi-sws.org Janardhan Iyengar Franklin & Marshall

“Zero-RTT” Transport Negotiation

Host A

Transport Negotiation “Meta-SYN”

Transport 1 SYN Transport 2 SYN Transport 3 SYN

Transport 2 SYN/ACK

Host B

time time

B choosesTransport 2