ITTC © James P.G. Sterbenz Communication...

Communication NetworksThe University of Kansas EECS 780

End-to-End Transport

James P.G. Sterbenz

Department of Electrical Engineering & Computer Science

Information Technology & Telecommunications Research Center

The University of Kansas

jpgs@eecs.ku.edu

http://www.ittc.ku.edu/~jpgs/courses/nets

03 October 2016 KU EECS 780 – Comm Nets – E2E Transport NET-TL-2

End-to-End TransportOutline

TL.1 Transport services and interfaces

TL.2 End-to-end functions and mechanisms

TL.3 Internet transport protocols

TL.4 Multipoint communication and reliable multicast

End-to-End TransportTL.1 Services and Interfaces

Transport LayerHybrid Layer/Plane Cube

Layer 4:

end-to-end

data transfer

in data and control planes

physical

network

transport

session

application

data plane control plane

management

socialL8

virtual linkL2.5

Transport LayerMotivation

Why do we need a transport protocol?

Transport LayerIdeal Network Model

• Ideal network model

– zero end-to-end delay

– unlimited end-to-end bandwidth

– perfect end-to-end transmission (no errors)

But what?

Transport LayerIdeal Network Model and Motivation

• Real networks are not ideal

• Need an end-to-end protocol to

– handle delay between communicating systems

– control transmission rate for bandwidth-limited paths

– perform error recovery

Transport LayerTransport Association Definition

• Transport association between end systems– transport connection in the case of connection state

– transport flow in the case of soft state or stateless

– may be point-to-point or multipoint

networkCPU

end system

intermediate

systemCPU

end system

Transport LayerEnd-to-End Protocol

• Transport protocol

– is responsible for end-to-end transfer of a TPDU

– note to Bell-heads: not layer 2 “transport network”

network

application

session

transport

network

end system

network

intermediate

system

network

intermediate

systemnetwork

intermediate

system

application

session

transport

network

end system

Transport LayerService and Interfaces1

• Transport layer (L4) service to application layer (L7)

• Transfer PDU (protocol date unit) E2E (end-to-end)– sender: encapsulate ADU into TPDU and transmit

– receiver: receive TPDU and decapsulate into ADU

• Multiplexing to application on end system

• Optional reliability:– error checking/correction/retransmission

– need depends on application

– may be done application-to-application (A2A)

• Flow control between end systems– assistance for network congestion control

Transport LayerService and Interfaces2

• Transport layer uses service of network layer (L3)

– network layer establishes a path through the network

• Transport mechanisms depend on L3 service

– datagrams vs. connections

– best effort vs. QoS

– error characteristics

– strength and symmetry of connectivity

What are the Internet assumptions & service model?

Transport LayerTypes of Transport Protocols

• Spectrum of transport protocol specialisation

– general purpose

• e.g. TCP (almost)

– functionally partitioned

• e.g. ISO TP0–4

– application-oriented

• e.g. RTP

– special purpose

• Software engineering and implementation choice

Transport LayerService and Interfaces

• Transport PDU encapsulates application data unit– ADU: application data unit

– TPDU: transport protocol data unit (segment if TCP or UDP)

– TPDU = header + ADU + opt. trailer (protocol dependent)

application layer

network layer

transport layer

application layer

network layer

transport layer

ADU ADU

ADU THADUH T TPDU

Transport LayerFunctional Placement

• Transport layer functionality only in end system

– host software or

– sometimes offloaded to network interface (NIC) EECS 881

switch

end system

network interface

mem CPU

frames

end system

network interface

memCPU

framespacket

Transport LayerEnd-to-End vs. Hop-by-Hop

• Transport layer is E2E analog of HBH link layer

– link layer (L2) transfers frames HBH

– network layer (L3) determines the path of hops

End-to-End vs. Hop-by-HopEnd-to-End Arguments

• The end-to-end arguments (1st half)

• Some functions can be correctly and completely implemented only at the endpoints of a communication association

• Providing these functions as features (only) in the network is not possible

paraphrased from [Saltzer, Reed, Clark 1981]

• Hop-by-Hop functions do not compose end-to-end

f1 f3-1

f3 f2-1

f2 f1-1

g g g g

• Hop-by-Hop functions do not compose end-to-end

– between HBH boundaries, function f is defeated (g)

• e.g. error control: errors may occur within switches

• e.g. encryption: cleartext within switches may be snooped

• These functions must be done E2E

– doing them HBH is redundant , and may lower performance

f1 f3-1

f3 f2-1

f2 f1-1

g g g g

• The end-to-end arguments (2nd half)

– performance enhancement corollary

• Functions should be duplicated hop-by-hop if there is an overall (end-to-end) performance benefit

paraphrased from [Saltzer, Reed, Clark 1981]

End-to-End vs. Hop-by-HopHop-by-Hop Performance Enhancement

• E2E Argument (1st half) says what must be E2E

• HBH Performance enhancement (2nd half)

– functions should duplicated HBH if overall E2E benefit

• Analysis is required to determine cost/benefit

– added functionality in net may add overhead not offset

End-to-End vs. Hop-by-HopPerformance Enhancement Example

• E2E vs. HBH error control for reliable communication– E2E argument says error control must be done E2E

• e.g. E2E ARQ (error check code and retransmit if necessary

– but should HBH error control also be done?

wireless LANUniv. Kansas

fiber LANUniv. Sydney

15 000 km

fiber WAN

End-to-End vs. Hop-by-HopPerformance Enhancement Example

• E2E vs. HBH error control for reliable communication– E2E argument says error control must be done E2E

• e.g. E2E ARQ (error check code and retransmit if necessary

– but should HBH error control also be done?

• Effect of high loss rate on wireless link– ~250 ms RTT retransmission for every corrupted packet

• Error control on wireless link reduces to ~1μs RTT– shorter control loop results in dramatically lower E2E delay

wireless LANUniv. Kansas

fiber LANUniv. Sydney

15 000 km

fiber WAN

End-to-End vs. Hop-by-HopSecurity

• Security and information assurance must be E2E

– information in the clear inside network nodes not secure

• Justification for HBH security mechanisms

– link security may be good enough for some

• wireless link encryption for WEP (wire equivalent protection)note: 802.11 WEP not strong enough

– subnetwork or edge-to-edge security for VPNs

• assures enterprise security across open network……but not individual flow security

End-to-End vs. Hop-by-Hop E2E Argument Misinterpretations

• E2E-only

– do not replicate E2E services or features HBH

– violates HBH performance enhancement corollary

• Everything E2E

– implement as many services or feature E2E as possible

– misstatement of Internet design philosophy:simple stateless network for resilience and survivability

End-to-End TransportTL.2 Functions and Mechanisms

TL.2.1 Framing and multiplexing

TL.2.2 State management and transfer modes

TL.2.3 Reliability and error control

TL.2.4 Transmission control

E2E Functions and MechanismsTL.2.1 Framing and Multiplexing

TL.3 Internet transport Protocols

E2E FramingStructure and Fields

• Delimits TPDU

– physical layer is coded bit stream

– receiver needs to delimit frames

• Header: how to process the TPDU

– protocol processing options

– demultiplexing fields: destination application identifier

• typically called port (Internet protocol suite terminology)

• ISO TSAPA: transport service access point address

• Trailer: what to do with the TPDU once arrived

– error check (CRC or checksum) for reliability

• most transport protocols have this in the header (e.g. TCP)

E2E MultiplexingConcepts

• Multiple applications use a particular TP

• Applications multiplexed into sending TP

– need to identify which application

E2E MultiplexingConcepts

• Multiple applications use a particular TP

• Applications multiplexed into sending TP

– need to identify which application

– using identifier typically called a port

• TP demultiplexes TPDU (segment)

– sending to correct application

– using port number

E2E Functions and MechanismsTL.2.2 Transfer Modes and State Management

E2E Functions and MechanismsTransport Protocol Service Categories

• Transfer mode– connectionless datagram

– connection-oriented

– transaction

– continuous media streaming

• Reliability

– loss tolerance

• Delivery order

– ordered

– unordered

• Traffic characteristics

E2E State ManagementControl Loops

Alternatives?

• Open loop

– control parameters

– no feedback

Alternative?

Open loop

parameters

• Open loop

– no feedback

• Closed loop

– initial parameters

– feedback

• dynamic adaptationdata

• Open loop

– no feedback

• Closed loop

– feedback

• dynamic adaptation

Open loop

parameters

Closed loop

initial parameters

E2E feedback

• Open loop

– no feedback

• Closed loop

– feedback

• dynamic adaptation

• Closed loopwith HBH feedback

• Nested control loops

Open loop

parameters

Nested control loops

initial parameters

E2E feedback

receiver sender

Closed loop with HBH feedback

HBH feedback

initial parameters

E2E feedback

Closed loop

initial parameters

E2E feedback

HBH loop

E2E State ManagementOpen- vs. Closed-Loop

• Open-loop control

– use when possible to eliminate control loop latency

• particularly for high bandwidth--delay product networks

• Closed-loop feedback control

– use when necessary, e.g. reliability

– aggressiveness of closed-loop control

• rapid enough to system converges

• not too aggressive avoid instability and oscillations

E2E State ManagementHard vs. Soft

• Hard state

– explicitly established and released

– deterministic

– delay to establish and memory to maintain

Alternative?

• Hard state

– deterministic

• Soft state

– established and removed as needed and memory allows

– robust to failures

– if not explicitly established, delay to accumulate

• Hard state

– deterministic

• Soft state

– established and removed as needed and memory allows

– robust to failures

– if not explicitly established, delay to accumulate

• Stateless

– (essentially) no state

E2E State ManagementAssumed Initial Conditions

• Improve performance of closed-loop control

– rapid convergence to steady state

• Assume initial conditions

– normal or common case

– past behaviour

– current network state (requires network dials)

E2E State ManagementImpact of Data Rate

• Transmission delay proportional to data rate

What happens when data rate increases?

RELEASE

• Connection shortening+ transmission delay decreases

– but signalling delay constant

slow fast

RELEASE

• Connection shortening+ transmission delay decreases

– but signalling delay constant

• E2E signalling– significant fraction of time

– connection shortening notproportional to Δ date rate

slow high-speed fast

~1.5tRTT

~2.5tRTT ACK

RELEASE ACK

RELEASE

SETUP SETUP

E2E State ManagementImpact of Path Length

• Transmission delayand path delay proportional to length

What happens when path length increases?

short links

RELEASE

E2E State ManagementImpact of Path Length

• Transmission delayand path delay proportional to length

• Connection lengthening– path delay increases

– signalling delay increases

• E2E signalling– open state longer

– denial of resource to others

short links long links

RELEASE

E2E Transfer ModesAlternatives

• End-to-end transfer modes– datagram

– connection

– stream

– transaction

E2E Transfer ModesDatagram

• Independent PDUs– each has fully self-describing header

– no end-to-end flow state needed to forward

E2E Transfer Modes Connection

• Explicit connection setup– 3-way handshake

SETUP / CONNECT / ACK

RELEASE

CONNECT

~1.5tRTT

E2E Transfer Modes Connection

• Explicit connection setup– 3-way handshake

SETUP / CONNECT / ACK

– both side have been acknowledged

• Data flow– PDUs need connection or flow identifier

• used by nodes to look up state

• Release of resources and state– explicit RELEASE

– time out state

RELEASE

CONNECT

~1.5tRTT

E2E Transfer ModesTransport and Network Connections

• Transport connections

– required over

• connectionless L3

• path with anyconnectionlesssubnetwork

– may exploit

• connection-oriented L3

SETUP CONNECT

network layer

end system

transport layer

connection-oriented network

network layer

end system

transport layer

setup-req

network layer connection

connectionless network

network layer

transport layer SETUP

CONNECT

network layer

transport layer

transport layer connection

network layer

transport layer SETUP

CONNECT

network layer

transport layer

connection-oriented

subnetwork

connectionless subnetwork

heterogeneous subnetworks

E2E Transfer Modes Connection State Machine

• ConnectionState Machine– send/receive paths

• States– idle

– establishing• install state

– initialising• state

convergence

– steady state

– closing• release state

initialising

steady state-

closing closing

establishing

CONNECT

from net

requested

receive

from net

originate

request

CONNECT

from net

RELEASE

from net

RELEASE

from app

RELEASE

E2E Transfer Modes Media Stream

• Various mechanisms to start stream– explicit client request

– server push

– may or may not establish connection state

• Data flow – synchronisation and control

• embedded or

• out-of-band

More about this in Lecture MS

REQUEST

RELEASE

CONNECT

E2E Transfer Modes Transaction

• Transaction request– may or may not establish connection state

– explicit release of connection state optional

• Data returned

• Overlap to reduce latency– request/response with control

• Recall: this is not how HTTP over TCP works

REQUEST

RELEASE

RESPONSE

E2E Functions and MechanismsTL.2.3 Reliability and Error Control

TL.2 End-to-End functions and mechanisms

E2E Error ControlTypes of Errors

What are the types of errors?

• Bit errors

types?

• Packet errors

types?

• Bit errors

• Packet errors

– packet loss

– fragment loss

– burst loss

– packet misordering

– packet insertion

– packet duplication

E2E Error ControlCauses of Bit Errors

• Bit errors

causes?

E2E Error ControlCauses of Bit Errors

• Bit errors

– flaky hardware

– wireless channels

• noise and interference

– optical channels

• long-haul fiber links engineered on margin with FEC

• control of amplifier and regenerator cost

ITTC © James P.G. Sterbenz Communication...

Documents

ITTC © James P.G. Sterbenz Introduction to Communication ...jpgs/courses/intronets/... · 30 October 2018 KU EECS 563 –Intro Comm Nets –Links & LANs ICN-LL-3 Link Layer Hybrid

Fundamentals and Design Principles - Sterbenz Family Web Pages

Session: Leadership Commitment Doug Sterbenz

ITTC Surface Treatment

End-to-End Transport - ITTCjpgs/courses/nets/lecture-transport-nets...End-to-End Transport 21 February 2011 © 2004–2007 James P.G ... ITTC © James P.G. Sterbenz End-to-End Transport

CPS Applications - ITTC

ITTC © James P.G. Sterbenz Science of Communication Networks · KU EECS SCN – Science of Nets – Graph Spectra . SCN-ST-12 . Graph Spectra . Applications in Computer Science •Expanders

A veriﬁcation of the ITTC/ISO speed/power trials analysis€¦ · · 2017-08-25A veriﬁcation of the ITTC/ISO speed/power trials analysis ... (ITTC) reported ‘ITTC ... The

ITTC © James P.G. Sterbenz Communication Networksjpgs/courses/nets/lecture-transport-nets-display.pdfCommunication Networks ... 03 October 2016 KU EECS 780 ... • Transport layer

James P.G. Sterbenz Science of Communication Networks …jpgs/courses/scinets/lecture-spectra... · ITTC © James P.G. Sterbenz 04 February 2016 rev. 16.1 © 2002-2016 James P.G

Resilience, Survivability, Heteorgeneity in Postmodern ... file14 October 2009 Resilience, Survivability, Heterogeneity in Postmodern Internet 7 ITTC Sterbenz, et al. Resilient Networks

ITTC © James P.G. Sterbenz High-Performance Networkingjpgs/courses/hsnets/lecture-admin-hsn-display-2017.pdf · doctor's notes from absent students –if you have concerns, call

ITTC © James P.G. Sterbenz Communication Networksjpgs/courses/nets/lecture-physical-display.pdf · ITTC © James P.G. Sterbenz 15 November 2017 KU EECS 780 –Comm Nets –Physical

ITTC © James P.G. Sterbenz Mobile Wireless Networkingjpgs/courses/mwnets/lecture-lab-intro2ns3... · 29 February 2016 rev. 16.0 © 2004–2016 James P.G. Sterbenz Mobile Wireless

Abstract - ITTC

ITTC © James P.G. Sterbenz Mobile Wireless Networkingjpgs/courses/mwnets/lecture-admin-mwn... · Mobile Wireless Networking AE.1 Administrivia ... •Lecture: Mon. 18:10 – 21

3.7 Physical Operation of Diodes - ITTC HOME | ITTC

ITTC © James P.G. Sterbenz Introduction to Communication ...jpgs/courses/intronets/lecture-mobilewireless-intronets...MAC Layer Service and Interfaces • MAC is in between physical

James P.G. Sterbenz Science of Communication …jpgs/courses/scinets/lecture-topology...ITTC © James P.G. Sterbenz 03 February 2017 rev. 17.1 © 2002-2017 James P.G. Sterbenz Science

Annual Report - ITTC