Flow Splitting in Tng, a Next-Generation Transport Architecture - - PowerPoint PPT Presentation

▶
flow splitting in tng a next generation transport
SMART_READER_LITE
LIVE PREVIEW

Flow Splitting in Tng, a Next-Generation Transport Architecture - - PowerPoint PPT Presentation

Nov 21, 2023 109 likes •483 views

Flow Splitting in Tng, a Next-Generation Transport Architecture Bryan Ford Janardhan Iyengar Max Planck Institute Franklin & Marshall for Software Systems College and Yale University jiyengar@fandm.edu baford@mpi-sws.org

slide-1
SLIDE 1

Flow Splitting in Tng, a Next-Generation Transport Architecture

Bryan Ford

Max Planck Institute for Software Systems and Yale University

baford@mpi-sws.org

Janardhan Iyengar

Franklin & Marshall College

jiyengar@fandm.edu

http://bford.info/tng/ Presentation for IETF 75 – July 27, 2009

slide-2
SLIDE 2

2

Relevant Documents

Papers/Drafts: “Breaking Up the Transport Logjam”

— HotNets '08: http://bford.info/pub/net/logjam.pdf

“Flow Splitting with Fate Sharing”

— Research draft: http://bford.info/pub/net/fowsplit.pdf

“A Next Generation Transport Services Architecture”

— Internet-Draft: draft-iyengar-ford-tng-00.txt

(Current) Project Web Page:

— http://bford.info/tng/

slide-3
SLIDE 3

3

The End-to-End Principle

In TCP/IP's original design, only the end hosts

— see past a packet's Network Layer (IP) header

▶ Generality: network carries any payload

— maintain “hard state” whose loss visibly impacts the user

▶ Fate Sharing: transports retransmit E2E,

can recover from failures in intermediate nodes

Network

End Host End Host

Link Application Network Link Application Network Link Network Link

Router Router

Transport Transport

slide-4
SLIDE 4

4

The Rise of the Middle

Internet scaling and diversity have led operators to place ever more intelligence in the middle

— Firewalls: enforce network access policies — Traffc shapers: manage network bandwidth & delay — Network Address Translators (NATs):

alleviate IPv4 address scarcity by sharing IP addresses

— Performance enhancing proxies (PEPs):

  • ptimize performance in problematic situations,

e.g., high-speed, high-delay, or wireless links [RFC3135]

This Talk's Focus

slide-5
SLIDE 5

5

Eroding End-to-Endness of Transports

Middleboxes need to interact with Transport Layer

— Firewalls, traffc shapers: to differentiate between

applications via TCP/UDP port numbers

— NATs: to modify IP addresses & port numbers — PEPs: to monitor & affect TCP congestion control

Result: the Transport Layer is no longer “End-to-End”

Network

End Host End Host

Link Application Network Link Application Network Link Network Link

Middlebox Middlebox

Transport Transport Application Application Transport Transport

slide-6
SLIDE 6

6

The Transport Layer's Lost Purity

Along with transport end-to-endness, we also lose:

— Generality: new transports can't pass → undeployable — Fate sharing: middlebox failures → hard TCP failures — Security: can't use transport-neutral security (IPsec)

Transports are still designed to, but now fail to, provide reliable end-to-end communication services

Network

End Host End Host

Link Application Network Link Application Network Link Network Link

Middlebox Middlebox

Transport Transport Application Application Transport Transport

slide-7
SLIDE 7

7

The Transport Layer is Stuck in an Evolutionary Logjam!

slide-8
SLIDE 8

8

Tng: Transport next-generation

Refactor transport layer to match reality

— Network-oriented functions of interest to middleboxes

  • Endpoints (ports); fow regulation (congestion control)

— Application-oriented functions serving the endpoints

  • Reliability, security

Data Link Layer Network Layer Application Layer Data Link Layer Network Layer Application Layer Endpoint Layer Flow Regulation Layer Semantic Layer Transport Layer Isolation Layer End-to-End Security Network-Oriented Functions Application-Oriented Functions

slide-9
SLIDE 9

9

End/Middle Coexistence

Tng's Key Beneft: enable middleboxes to

— interact cleanly with network-oriented functions — avoid interfering with E2E application-oriented functions

Network

End Host End Host

Link Network Link Network Link Network Link

Middlebox Middlebox

Application Application Endpoint Flow Semantic Isolation Endpoint Flow Semantic Isolation Endpoint Flow Endpoint Flow

slide-10
SLIDE 10

10

Example Tng Protocol Stack

Can implement Tng using only “legacy” protocols

— Workable design; not ideal in function or effciency

Link Layer Network Layer Application Layer Endpoint Layer Flow Regulation Layer Semantic Layer Isolation Layer End-to-End Security Network-Oriented Functions Application-Oriented Functions 802.11 IP HTTP UDP DCCP TCP (CC disabled) DTLS

Functional Layer Legacy Protocol

slide-11
SLIDE 11

11

Endpoint Layer

edge routing needs richer endpoint information to enforce policy

Physical Layer Data Link Layer Network Layer Application Layer Flow Regulation Layer Semantic Layer Isolation Layer Endpoint Layer

slide-12
SLIDE 12

12

TCP Header TCP Header UDP Header UDP Header DCCP Header DCCP Header

Endpoint Identifcation via Ports

Each transport traditionally has its own port space

IP Header IP Header

Source Port Dest Port Source Port Dest Port Source Port Dest Port Source IP Address Dest IP Address

TCP Port Space UDP Port Space DCCP Port Space Network Layer IP Address Space

slide-13
SLIDE 13

13

Why the Network Needs to See Ports

Internet design assumes network needs only IP address

— (e.g., only IP address appears in every fragment)

Assumption has proven wrong!

  • Firewalls, traffc shapers need to see them

— to enforce connectivity policies, need to know about

not just hosts but also protocols, applications, users, ...

  • NATs need to see & transform them

— IPv4: ports increasingly just “16 more IP address bits”

  • All must understand transport headers

— ⇒ only TCP, UDP get through now

slide-14
SLIDE 14

14

Tng's Layering Solution

Factor endpoints into shared Endpoint Layer

— Starting point “Endpoint Layer” = UDP

Transport Header Transport Header Transport Header Transport Header Network Header (IP) Network Header (IP)

Source IP Address Dest IP Address

Endpoint Layer Port Space Network Layer IP Address Space Endpoint Header (UDP) Endpoint Header (UDP)

Source Port Dest Port

slide-15
SLIDE 15

15

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]

  • A lot of non-transports do too

— IPSEC [RFC 3947/3948], Mobile IP [RFC 3519],

Teredo [RFC 4380], …

Other benefts: see “Breaking Up the Transport Logjam”

slide-16
SLIDE 16

16

Flow Layer

performance tuning at technology & administrative boundaries

Physical Layer Data Link Layer Network Layer Application Layer Semantic Layer Isolation Layer Endpoint Layer Flow Regulation Layer

slide-17
SLIDE 17

17

Congestion Control

  • n a Diverse Internet

TCP congestion control traditionally “end-to-end” But one end-to-end path may cross many...

— different network technologies

  • Wired LAN, WAN, WiFi, Cellular, AdHoc, Satellite, …
  • Standard TCP performance sucks on many of these;

needs specialized adaptation!

— different administrative domains

  • Each cares about CC algorithms in use, for fairness
  • May wish to deploy new CC schemes, e.g., XCP/RCP
slide-18
SLIDE 18

18

Emerging Market Solution

Performance Enhancing Proxies (PEPs)

  • Tune TCP performance within the network
  • Increasingly pervasive; may be “the next NAT”:

— $236 million market in 2005 [Hall 2006] — $1 billion market in 2009 [McGillicuddy 2009]

  • Breaks: fate sharing, new transports, IPsec

[RFC3135]

LAN LAN

Host Host PEP PEP

Cisco RBSCP

slide-19
SLIDE 19

19

Tng Solution: Flow Splitting

Decompose congestion control (Flow Layer) from transport semantics (Semantic Layer)

— PEPs interpose on Flow Layer but not Semantic Layer

Network

End Host End Host

Link Network Link Network Link Network Link

Flow Middlebox Flow Middlebox

Application Application Endpoint Flow Semantic Isolation Endpoint Flow Semantic Isolation Endpoint Flow Endpoint Flow

slide-20
SLIDE 20

20

Technical Challenges

May (or may not) look easy; the devil's in the details:

  • Joining: how to join congestion-controlled path

sections into E2E congestion-controlled path?

  • Compatibility: how to deploy Tng incrementally,

staying compatible with existing networks & PEPs?

slide-21
SLIDE 21

21

How to Join Flow Segments to yield End-to-End Congestion Control?

Endpoint Flow

Host A Host B

Network Semantic Application Endpoint Flow Network Semantic Application Endpoint Flow Network Endpoint Flow Network

Flow Middlebox Flow Middlebox

Exploring two approaches: 1) Queue sharing (implemented) 2) Congestion control stacking (WIP)

slide-22
SLIDE 22

22

Queue Sharing

Net Source Host Flow Middlebox Router Router Router Router Target Host App Net App Congestion Control Loop 1 Congestion Control Loop 2 Transmit Buffer Receive Buffer Feedback

(ACKs, etc.)

Feedback

(ACKs, etc.)

(1) (1) Link Link Bottleneck Bottleneck (3) (3) “Packets “Packets Dropped!” Dropped!” (4) (4) “Slow “Slow Down!” Down!” (5) (5) Queue Queue Fills Fills (6) (6) “Packets “Packets Dropped!” Dropped!” (7) (7) “Slow “Slow Down!” Down!” (2) (2) Queue Queue Fills Fills

(implemented in NS2 simulation & working prototype)

slide-23
SLIDE 23

23

Congestion Control Stacking

Net Source Host Flow Middlebox Router Router Router Router Target Host App Net App

(work in progress)

Segment 1 Control Loop Segment 2 Control Loop End-2-End Congestion Control Loop (e.g., XCP)

“Virtual Router” Input Queue

slide-24
SLIDE 24

24

Compatibility with Legacy PEPs

How to deploy Tng incrementally, given prevalence of PEPs that know only TCP?

— Prefer DCCP-like protocol implementing Flow Layer... — But fall back on TCP as “compatibility Flow Layer”

Network Application Endpoint Flow Semantic

IP HTTP, SIP, ... Legacy TCP Flow New Semantic Layer Protocol IP New Endpoint Protocol New Flow Protocol

slide-25
SLIDE 25

25

Evaluation

Using:

  • NS2-based Simulations

— Building on NS2's models of TCP congestion control

  • Working prototype usable on real networks

— Building on Structured Stream Transport (SST)

Ford, “Structured Streams: a New Transport Abstraction”, SIGCOMM 2007

slide-26
SLIDE 26

26

SST

  • Based Prototype Structure

Stream Protocol Channel Protocol (authentication, encryption) Negotiation Protocol (key exchange) UDP Application Protocol

Semantic Layer

Reliable Byte Streams End-to-End Channels UDP Datagrams Channel Protocol (congestion control) Negotiation Protocol Segmented Channels IP IP Packets

Isolation Layer Flow Regulation Layer Network Layer Endpoint Layer Application Layer

slide-27
SLIDE 27

27

Ad Hoc Wireless Network Wired Internet Mobile Wireless Link

Simulation Scenario 1

Last-mile proxies for wireless/mobile links

Flow MidB Flow MidB Host Host

Mobility-Aware Congestion Control [M-TCP, ELFN, ...] TCP-friendly Congestion Control [Reno, TFRC, ...] Ad Hoc Wireless Congestion Control [WTCP, ATCP, ...]

slide-28
SLIDE 28

28

Simulation Scenario 1: Results

Download Upload

Flow MidB Flow MidB Host Host

Wireless Wireless Wired

Host Host

Wireless Wireless Wired

End-to-End: Wireless Loss Kills TCP Performance With Flow Splitting: Performance Maintained

slide-29
SLIDE 29

29

Simulation Scenario 2

Delay-Sensitive Use of DSL/Cable Links

Low-Delay Congestion Control TCP-friendly Congestion Control 1 M b p s 2 m s ADSL link

Up: 384Kbps,10ms Dn: 1.5Mbps,10ms

10Mbps 10ms 100Mbps 20ms Cross-traffic access links: 100Mbps, 25ms Cross-traffic source/sink Router1 Router2 Server Client Gateway

slide-30
SLIDE 30

30

Simulation Scenario 2: Results

Upload Bandwidth Upload Latency

Flow MidB Host Host

Cable/DSL Internet

Host Host

End-to-End Vegas: Low Latency, but Loses to Cross-Traffic With Flow Splitting: High Bandwidth + Low Latency

Host Host

End-to-End Reno: High Bandwidth, but Causes High Latency

Cable/DSL Internet Cable/DSL Internet Vegas Reno

slide-31
SLIDE 31

31

LAN LAN

Prototype Test Scenario 1

Transfer over Lossy Long-Distance Satellite Link

Host Host

TCP-friendly CC [Reno, TFRC, ...]

Flow MidB

TCP-friendly CC [Reno, TFRC, ...] Specialized/High-Performance CC [HS-TCP, Scalable TCP, BIC-TCP, ...]

Flow MidB

LAN LAN

Host Host Flow MidB Flow MidB

slide-32
SLIDE 32

32

Reliable Transfer over Satellite Link

slide-33
SLIDE 33

33

Prototype Test Scenario 2

Fate Sharing: recovery of end-to-end stream communication across fow layer failures

  • SST Stream Protocol associates streams

with stable cryptographic endpoint identities

  • Underlying Flow fails if a host's IP address changes,

but stream can (re)start and migrate to new fow

Stream Stream

End-to-End Reliability

Flow A Flow A

EID 1 EID 2 IP A1 IP A1

Flow B Flow B

IP A2 IP A1 Internet

slide-34
SLIDE 34

34

Prototype Test Scenario 2

Mobile end host starts fle transfer at time 0, IP address changes at 10 sec.

slide-35
SLIDE 35

35

“Clean Slate” versus “Legacy” Implementation of Tng Architecture

Code size and Protocol Overhead Comparison

— Current SST Prototype vs Equivalent Linux Protocols — C++ vs C, prototype vs mature stacks – not really fair!

slide-36
SLIDE 36

36

Conclusion

Transport evolution is stuck!

— Lost: transport evolvability,

E2E security, fate sharing

T

  • unstick, need to refactor:

— Enable middleboxes to function

without interfering with end-to-end transport functions

Tng allows performance enhancing proxies to split fows and tune congestion control while preserving end-to-end semantics Further information: http://bford.info/tng/