Trasport Layer Protocols

• stream oriented

• -> in-sequence delivery of byte stream…

• Bit error detection

• TSDU (Transport service Data Unit9 -> loss detection and retransmission

• Flow control

• Congestion Control

• point-to-point (one sender, one receiver)

• reliable (retransmission of lost segments)

• in-order

• stream oriented

• conection oriented (after handshake till teardown)

• flow controlled

• congestion controlled

• source port

• destinaiton port

• sequence number

• acknowledgement number

• offset

• reserved bit

• window (size of receiver window, used for flow cotrol)

• flags

• checksum

• urgend pointer

• options

  
  

• urgent

• acknowledgement

• push

• reset

• syn

• fin

• ACK not received in certain time interval

  • timeout occurs

  • sender retransmits segment

• Multiple duplikate ACK arrive

  • cause: reorder or packet loss

    
    

• timeout + 1 RTT

• => first, timer has to timeout and then 1/2 RTT retransmission and 1/2 RTT ACK

• when arriving 3 duplicate ACK

• -> mechanism to quickly send missing segment

• longer than RTT -> as else would timeout even when segment is not lost

• -> but RTT varies!!!

• high: slow reaction to segment loss

• low: premature timeout; unneccessary retransmisisons (spurious rertansmission)

• sample from duration sending <-> receiving ACK (ignore retransmissions)

• can vary due to many factors -> want sth. smoother…

• => EWMA

• exponential weighted moving average

• -> way to smoothly estimate the RTT

• such that influence of older RTT decreases and more weight on recent samples …

• EstimatedRTT = (1 − α) · EstimatedRTT + α · SampleRTT

• with typical value: α = 0.125

• MSS option

• TCP timestamp option

• selective acknowledgement options

• tcp window scale option

• anounce MSS during handshake -> accept no segments larger than MSS

• can be completely independently in each direction

• MSS counts only data octets in the segment -> does not count the TCP / IP header..

• used to make sure that ACK are unique (from first of from re transmission???)

• -> sender and receiver run a timestamp clock for segments

• -> append two timestamps to each segment

  • TSVal -> current Timestamp when segment is sent

  • TSecr (TS echo reply): latest TSVal received before segment is sent

• => receiver computes TSecr - current timestamp to get RTT

• => used to provide more informaiton about the lost segment(s) -> i.e. every second was lost…

• => makes selective retransmission possible instead of go-back-n…

• possibly limited receiving. capacity on receiver side

• => e.g. OS kernel buffers segments for applicatons to process

• -> buffer is of limited size…

• => negotiate maximum amount of data to receive (window field in header)

• send only so much data that the network won’t get overwhelmed

• and try to divide the bandwidh in a fair manner between senders

• lost packets (buffer overflow at routers)

• long delays (router buffers queues fill up)

• effective

• simple

• robust

• end-host driven

• Application Limited -> inflight < BDP

• bandwidth limited ->BDP < inflight < BDP + BtlneckBufSiz

• Buffer limited BDP+BtlBufSiz < inflight

• round trip propagation delay

• -> Sum over delays of each link of a path

• Bottleneck Bandwidth

• -> minimum bandwidh over all links on a paht…

• RTProp * BtlBw -> AMount of inflight the path can hold without relying on buffers…

• data which is sent but not yet acknowledged

• product measure

• epsilon fiarnes

• jains fairness index

• simply product over all bandwidths

• rate allocation called epsioon fair if:

• (min bandwidth / max bandwidth) >= 1-epsilon

• => the difference between minimum and maximum bandwidth is delimited by an epsilon…

• sum of bandwidths squared

• divided by

• n times sum of squared bandwidths

=> kind of softmax..

• if it is k/n -> then htere are k flows perfectly fair while the other n-k shares are 0…

• has well-defined number of data / segments that can be sent without receiving an ACK first…

• => congestion window…

• congestion control based

• flow control based

• reno

• cubic

• bic

• AIMD -> Additive Increase Multiplicative Decrease

• two modes of operation: slow start and congestion avoidace

  
  

• CWND -> Congestion Window, limits amount of inflight

• ssthresh -> Slow start threshold

• increase CWND for each received acknowledgement by 1 for each ACk MSS

• as long as CWND < ssthresh

• for every received ack -> increase CWND by 1/CWND

• effectively increase CWND by 1 each RTT… (-> additive increase)

• use this when CWND >= ssthresh

• receive 3 duplicate ACK

  • -> set ssthresh to CWND / 2

  • set CWND to ssthresh (-> fast recovery)

• ACK timeout

  • set ssthresh to CWND / 2

  • set CWND to 1 MSS

  • restart with slow start…

• low performance on lossy links (-> as never gets back up due to constant decresase…)

• buffers are filled

• increase depends on RTT -> slow growth on long distance links

• has problems fully utilizing large BDP links

• loss based congestion control algorithm

• max bandwidth is estimated and if no loss occurs -> probing for higher bandwidth…

• W_cubic -> Congestion window according to TCP cubic

• W_max -> window size at which last packet loss occured

• t -> time since last packet loss

• ß -> windows decrease constant for multiplicative decrease of window

• C -> Cubic parameter

• W_cubic(t) = C * (t-K)^3 + W_max

• K = third root(W_max * (1-ß_cubic)/C)

• C = 0.4

• ß = 0.7

• congestion window not halved for evetry packet loss (ß=0.7)

• congestoin window growth modeled after cubic function with plateau W_cubic

• converges fast (concave growth) towards bandwidth of last packet loss W_cubic (estimated network maximum)

• if this is fine, higher bandwidht explored (convex growth…)

  
  

Advantages:

• CWND growh is independent of the RTT

• Scalable for high BDP networks

• More resilient against single stochastic packet loss than renp

Disadvantages:

• buffers are filled faster (cubic growth function)

• buffers are kept full (reduced only by 30% after packet loss)

  
  

Difference:

• use delay instead of loss to detect congestion

• increse in RTT -> a buffer is filling ip somewhere…

Advantages:

• less restraned by random packet loss

• early congestion detetion

• high throughput with low latency

Disadvantages:

• one loss-based flow cancels all advantages

• poor performance against loss-based flows

• Delay based

• -> AIAD -> additive increase additive derease

• calculates delta = CWND * (RTT - RTT_min) / RTT

• if delta > ß -> window size decreased by 1 MSS

• if delta < alpha -> window size increased by 1 MSS

• if alpha < delta < ß -> steady state -> no modifications…

• congestion control algo that is not really delay based but works on the same operating point as delay based algos…

• BBR -> bottleneck bandwidth and RTT…

• ACK-Clocking -> used by Reno, Cubic, Vegas,…

• CWND limits the inflight data BUT sending rate not limited…!

• arrival rate of ACKS determine the sending rate

• traffic bursts can create queues even if link not utilized

• => can be caused by slow start, retansmissions, ACK comüression….

Pacing:

• goal: evenly space trasmissions of packets of a window across entire RTT

• => queuing discipline…

• keep 1 BDP of data inflight -> full link utilization and no queuing delay…

• send with the bottleneck abndwidth -> no queue can build up…

• continuously monitor network to find minimal RTT and maximum bandwidth

• use RTProp and BtlBw as associated parameters…

• cannot be measured at the same time

• -> sequential measuring in different phases…

• startup

• drain

• probe bandwidth

• probe roud-trip-time

• double sending rate each RTT

• stop after three consecutive RTT with less than 25% in delivery rate increase

• => finds BtlBw in log2(BDP) RTTs

• can creae queue up to 2 BDP

• goal: remove queue created during startup…

• -> sending rate = BtlBw * (ln2/2)

• leave drain when data in flight matches estimated BDP…

• periodically probe for more bandwidth

• -> estimate BtlBw using max filter of length about ten etsimated RTTs

• => sending rate = BtlWb * Pacing Gain (:= [1.25,0.75,1,1,1,1,1,1])

• each setp takes about one RTT

• -> if no bandwidth available -> sending rate reduced afterwards to remove queue

• -> if available -> BtlBw is updated and thus sending rate increases…

• Estimate RTProp with min filter of lenght 10s

• -> of no new RTProp value measured during this interval

  • -> BBR enters probe RTT

1. Ensure queues are empty -> BBR reduces inflight to 4 segments for 200ms + RTT

• Problem: low deliivery rate during probe RTT -> performance drop…

• multiple BBR flows have to snychronize their Probe RTT phases to reach fairness…

• robustness against random packet loss

• low delay

• high bandwidth usage

• close to optimal operating point

• does not starve when competing with other algorithms

• numerous BBR flows fail to keep buffer empty

  • -> flows probe alternating for more bandwidth

  • -> sum of bandwidth estimations larger than actual bandwidth

  • -> create persistent queue of ~1.5 BDP

• High number of retransmissions in networks with shallow buffers

  • -< if buffer smaller than the persistent queue -> packet loss

  • BBR does not react to loss

  • with small (shallow) buffers -> BBR can generate ~ 20% retransmissions…

• RTT unfairness

  • BBR flows with larger RTT receive larger bandwidth shares than flows wiht lower RTT

  • with reno and cubic, flows with lower RTT are favored…

• during probe RTT -> reduce cwnd to 50% instead of 4 packets

• consider detected packet loss for model

• inforporate protocol features like ecn

• handle problems with ACK aggregation

• better coexistence with reno / cubic

• leave space for new entering flows

• yes

• Source Port

• Destination Port

• Length

• Checksum

• stream control tansmission protocol

• combines advantages of TCP and UDP

• multiple streams

• supports of multi-homing

• TCP already established as default transport layer protocol

• poor support in OS and applicatoins

• many middleboxes (e.g. firewalls, NAT) do not work with sctp -> packets are discarded…

• quick udp internet conections -> but not acronym…

• substitute for TCP/TLS protocol stack, based on UDP

• decrease handshake time

• get rid of head-of-line blocking

• faster development cycles

• middlebox resistance

• IP mobility

• Connection ID

• Stream multiplexing

• dofferent frame types

• flow control

• congestion control

• different packet types

• encryptinon and authentication

• loss detection and re-ordering

• id used instead of the IP-5 tuple

• -> allows change of IP and Port…

• multiple streams within a single connection (like IP -> Port -> Stream…)

• each stream provides reliable bi-directional bytestream

• QUIC packet contains several frames

• -> QUIC packet can carry stream frames from multiple streams

• control frames

• data frames

• acknowledgement frames

• stream flow control

• connection flow control

• currently cubic

• -> BBR implementation in progress…

• version negotiation packet

• initial packet

• retry packet

• handshake packet

• always

• -> using TLC 1.3

• retransmissions have different packet number -> use stream offset for in-order delivery….

• more elaborated acknowledgement mechanism including selective and negative ACK’s (SACKs and NACKs)

• TCP does 3-way, and TLS at least 3-way handshake

• => lots of RTT before actual data transmission…

• can be reduced using e.g. TCP fast open (but not widely deployed)

  
  

  
  

• Solution: Introduce 0-RTT and 1-RTT handshake

• merge TCP and TLS components into one protocol

• reuse old connections

• client saves information about the server

1. Inchoate CHLO

2. REJ

3.1 Complete CHLO

3.2 Encrypted Request

4.1 SHLO

4.2 Encrypted Response

1. Coplete CHLO & Encrypted Request

2. SHLO & Encrypted Response

1. Complete CHLO & Encrypted Request

2. Rej

3. Complete CHLO & Encrypted Request

4. SHLO & Encrypted Response

• if one segmetn is lost -> all segments after that have to wait (in-order delivery)

• -> frequent goal: multiplexing multiple data streams over one TCP connectoin (as loss in one stream does not block other streams…)

• protocol aware of multiple streams

• retransmission done at stream-level, not connection level…

• TCP implemented in kernel

• -> slow deployment of new machanisms…

  • devices often dont get updated to newer kernel

  • getting modificatoins of kernel protocol mechanisms slow process

  • involves lots of testing with lot of different applicatios

  • running big-scake experiments with tcp very difficult

Solution:

• QUIC based on UDP -> implemented in user space…

• kernel is not involved in protocol itself…

• experiments with new protocol mechanisms are straightforward as long as user-space is controlled by application vendor…

Problem:

• moddlebixes exist -> make things wors as may lead to boscure behavior

• -> are produces by many different vendors/manufacturers

• -> getting along with middleboxes like herding cats…

Solution:

• encrypt data stream transported by UDP

• -> protocol headers above are not accessible by middeboxes…

• TCP-like optimizers are not possible due to encryption

Problem:

• TCP connections identified by IP5-tuple

• -> Client IP address may change during connectoin

• DSL connections get re-established after 24h

• mobile clients move from one network to another…

• NAT entry might expire -> port changes…

Solutino:

• do not use IP-5 tuple as connection indentifier…

• -> QUIC identifies connetios by a conneciton ID

• => Last client IP adress to send valid packet for given Connection ID -> is the current IP address of the client

• more than one

• not all implementations compatible with each other

  
  

• standardized 2016

• -> 5 key goals:

  • minimizin connetion establishment and overall transport latency for applicatoins

  • providign multiplexing without head-of-line blocking

  • requiring only changes to path endpoints to enable deployment

  • enabling multipath and forward error correction extensions

  • providing always-secure transport using TLS 1.3 by default

• long header (only used for initial 0-RTT handshake and retry packets)

• short header

  • used after connection is established

  • designed for minimal overhead

• Type

• Type-specific

• version

• DCID Len

• Destination Connection ID

• SCID Len

• Source Connectoin ID

• Destination Connection ID

• Packet Number

• UDP datagram

• -> encapsulates one or more QUIC packet

• -> Can contain more than one QUIC frame (different streams…)

• UDP: Ports, Checksum

• QUIC packet: Connectoin ID, Packet Number

  • Packet Number used to determine cryptog. Nonce for packet protection

  • differnet packet number spaces for initial packets, handshake packets and application packets

  • start at packet number 0 and must be increased by at least 1 for subsequent packets

• QUIC frame:

  • tpyes: padding, ping, ack, stream

  • -> some frame types only allowed in certain packet types… (e.g. at onnetion start / end…)

• Initial and Handshake

  • carries first CRYPTO frames and ACKs sent by client and server to perform key exchange

• 0-RTT

  • used to carry early data from client to server as part of first flight, prior to handshake completion

• 1-RTT

  • used with the short header once 1-RTT keys are available

• ensures that smaller integer values need fewer bytes to encode

• -> the two most significant bits of the first byte encode the log2 of the integer encoding length in bytes

• -> e.g. 01 -> 2 bytes; 00 -> 1 Byte; 10 -> 4 bytes

• (and always - 2 bits as they are used to indicate length…)

• confidentiality (only encrypted data transfer)

• authenticatoin (server is authenticated, client optinoally)

• integrity (message authentication codes)

• TLS 1.3

  • faster handshake (i.e. supports 0-RTT handshake)

  • removes several outdated/insecure copher suites

  • only supports AEAD algos

• AEAD

  • authenticated encrption with associated data

  • encrpyt and compute MAC sumultaneously

  • -> Encrypt C = f(k,N,A,P)

  • -> Decrypt P = f(k,N,A,C) shouldd return an error if integrity check fails…

• Nonce = Packet number (in header) xor IV

• Ciphertext = AEAD(Header (associated data) , payload, nonce, key)

• Protected Payload = Ciphertext

• -> Add header protection by:

  • encrypt certain 128 bit of ciphertext with hp key

  • mask so that only some header fields are protected (e.g. packet number) and then xor with header

• Remove header protection

• compute packet nonce N

• compute P= AEAD(key, N, associated data, C)

• handshake combines transport and cryptovraphic handdshake (-> e.g- TCP plus TLS in one…)

• perform authenticated key exchange

  • server always authenticated with e.g. certificate

  • client is optionally authenticated

• authenticated exchange of vlaues for transport parameters

  • e.g. max idel timeout, max udo payload siue, initial max data,…

• negotiate connection IDs

• Packet Type[Packet Number]: Frame Type[Content], Frame Type[Content],…

• e.g. Initial[0] : CRYPTO[SH], ACK[0]

• versions identified by 32-bit unsigned number

• 0x0000 0000 reserved to represent negotiation…

Procedure:

• client sends used version in the long header

• if version not supported by server, replies with version negotiation packet listing all supported versions (own version set to 0x00000000)

• client can pick a supported version…

• Lightweight, ordered byte-stream abstraction

• Bidirectional or unidirectional

• Stream frames can open, carry data for, or close a stream

• Unique stream ID (62-bit integer), two bits used to identify initiator and if bi- or unidirectional

• Multiple streams are sent interleaved, streams can be prioritized (avoidance of head-of-line blocking)

• Packet numbers are acknowledged, after all frames have been processed

• Tries to send ACK frames as often as possible to improve loss and congestion response

• Trade-off between load generation and short response times

• ACK frame contains multiple ACK ranges

• As most of QUIC PDU is encrypted

• -> passive monitoring is hard…

• => introduce mechanism that allows for measurement of the connections RTT

  
  

Mechanism:

• set spin bit initially to 1

• -> spin bit is simply reflected by the server

• -> if the client receives the same flip bit it is currently sending -> invert it…

=> RTT = time without change in the flip bit…

• qlog

• qvis