Transport Layer

• transport layer protocol

• connectinoless IP datagram service

• applications that do not need reliable connections

• applications that would have problems with rertansmissions, flow control, congestion control, etc.

• DNS

• SNMP

• RIP

• RADIUS

• traceroute

• tftp

• video and audio streaming

• source port

• destination port

• length

• checksum

• no

• -> no retransmissions

• -> no acknowledgement that packets are received…

• protocol for end-to-end host communication

• connectoin oriented

• reliable

• provides flow and congestion control

• socket interface (IP, Port) for application layer

• e.g. HTTP, FTP, Telnet, ssh, dns, POP3/IMAP,…

• Ports

• sequence number

• acknowledgemnet

• TCP header length

• 6 bit unused

• Flags

• Window

• checksum

• urgent pointer

• options

• urgent flag

• ack

• psh

• rst

• syn

• fin

• fin ->

• <- ack

• <- fin

• ack ->

• syn, syn ack, ack

• -> initiall sequence numbers in the syn

• acknowledgement of the next sequence number (after the ones received…)

• does not want to send data anymore

• occurence of a protocol error…

• mechanism to avoid that receiver is overwhelmed (more data that it can handle…)

• sliding window approach

• -> sender may only send certain amount of data (fitting in a window)

• -> as soon as ack is received -> window advances to next unacknowledged byte….

• amount of data that was sent but not yet acknowledged…

• when segment is not acknowledged within certain timespan

• -> assume segment was lost

• -> retransmit beginning from last unacknowledged bytes…

• meachanism to avoid ovreloading the network

• and fairly distribute the badnwidth on bottlenecks

• used for local addressing on thehosts (addressing of applications)

• -> together with IP -> provide socket interface

• => allow for multiple paralell communications on single host by addressing the application as communication partner and not the host itself…

• the sequence number of the next packet the recipient expects

• vanilla TCP not

• -> after timeout, retransmits all segments from first unackknowledged sequence number (go back n)

• -> exception: TCP SACK (selective acknowledgement)

• TCP receiver buffers out-of-order segments if their sequence numbers are within current window

Instead of sending an individual ACK, the ACK is sent with a TCP segment that also transmits data

• when time stamp otion is used -> use timestamp…

• Karns algo (all TCP implementations have to use)

  • values for retransmitted algos cannot be used to estimate RTT and determining value of retransmission time

• timer value based on estimates for RTT and its deviation

  • -> increase in RTT leads to larger time values

• measured RTT increases -> vlaue of timer increases

• additive increase multiplicative decrease

• increase data rate slowly (linear growth) but decrease with multiple factor a<1 in case of transmission error

• no

-> has shown to be too conservative

-> leaves significant part of bandwidth unused

• TCP cubic algorithm

• -> makes better use of avaialbe bandwidth

• -> expecially in fast networks with high RTT

• adjust sending rate of TCP sender to current conditions in the network

• -> network congested => reduce sending ratet

• -> network not congested => increase sending rate

• congestion window

• -> limits number of segments that can be sent without waiting for acknowledgement

  
  

• min (Congestion window, flow window)

• congestion window (cwnd)

• slow-start threshold (ssthresh)

• cwnd: one segment

• sstrhesh: 65545 bytes

two phases

• slow start

• congestion avoidance

• cwnd < ssthresh

• cwnd > ssthresh

• wcnd is increased by one for each arrived ack

• => doubling cwnd for each RTT (as each RTT double the amount of segments are sent -> double of ACK received..)

• cwnd set by calculating cubic funciton

• depending on:

  • time since last packet loss

  • cwnd at the time of the pacekt loss

• a segment is lost

• => meaning: retransmission timer has timeout

• OR

• three duplicaete ACKs arrive

• timeout

  • -> ssthresh to 4/5 fo current value of cwnd

  • -> cwnd set to onw

  • => start from slow-start…

• 3 duplicate ACKS:

  • -> perform fast recovery

  • ssthresh to 4/5 of current cwnd value

  • cwnd set to new value of ssthresh

• to avoid waiting for timeout

• -> think that 3 duplicate ACKs indicate an error…

• packet loss (only) caused by congestion

• connections with small RTT no congestion

• network hardware growing in size and speed

• bandwidth increases to gigabit

• buffers can grow almost arbitrarily -> memory is cheap

=> BBR to adapt better to altered HW conditions

• does not know by itself wether network is congested

• -> requires “proxy” metric…

• assumes that each loss is happening due to congestion

• TCP Reno -> Sawtooth graph

• TCP Cubic

• produt of a links RTT and the links bandwidth

• -> RTT * Bandwidth

• => Data that fits on the link…

• Loss based congestion control only begins to work, when buffers are full

• -> burrers full -> packets get dropped (loss) -> Congestion control reduces window

• -> buffers get emptied -> congestion control thinks, one can increase window -> buffers fill up again…

• RTT stays the same until amount in flight equals the BDP

• After that, it increases until it reaches BDP + Buff size

• => No more data can be put on the link and hold in the buffers -> Cubic / Reno starts to kick in

• Delivery Rate incrases until amount of inflight = BDP (as then, more traffic only means buffers fill up and not that more is delivered)

• -> stays the same until BDP + Budd Size is reached, as then drop happens and CUBIC / RENO kicks in

  
  

• max delivery rate and min RTT

• => BDP = amount inflight

=> used in congestion based congestion control (as there, the actual congestrion is tried to estimate…)

• bottleneck link is saturated without sending so much that queues get filled up and RTT increase…

• not sending too little so that not full capacity of bottleneck link is used

  
  

• Rount trip time

• Bottleneck bandwidth

• BBR runs timer for each segment to measure time until according ACK arrives

• -> estimator for the RTT

• => takes minimum value of certain amount of segments as RTT

• RTProp -> approximates RTT with measured values of RTT

• use RTprop to calculate how much data was delivered in what time (based on the sent segments…)

• -> maximum delivery rate out of certain time interval as bottleneck bandwidth

• to do as exactly as posisble -> buffers on the link must be empty

• -> else, aditional querying delay would be included…

• to sample bandwidht -> have to increase sending rate until loss occures -> fill up buffers

• negative efects on RTT measurement…

=> impossible to sample both at the same time

-> sampled sequentially…

• program that simulates / generates real looking traffic

• ttcp…

• port muptiplexing / demultiplexing

• error checking

UDP

• simple and lightweight

• unreliable

• message-oriented

• stateless

• good choice for time-critical applications

• supports unidirectional communication

TCP

• complex

• reliable → head-of-line blocking

• stream-oriented

• sending-rate adaption

• vulnerable to resource exploitation

• congestion control may be too restrictive, e.g. wireless networks

• unlimited sending rate may overload network/receiver

• port multiplexing / demultiplexing

• error checking

• reliable and ordered delivery

• stream-orientation

• control of sending-rate (avoid overloading the network or the receiver)

• reliable, connection oriented protocol

• => needs a way of determining wether segments arrived…

• an ack acknowledges all smaller sequence numbers

• head of line blocking

• -> SEQ 3-5 were recieved

• -> three ack=2

• -> retransmits seq=2 -> others bufferd before this… blocking the head of line…

• establish initial sequence numbers and window sizes

• negotiate options

• vulnerable to syn-flood attacks

• -> (D)DoS -> flood with 3-way handshakes to all ports

• => mitigation: TCP Syn cookies

• 4-way handshake

• each side needs to close connection -> half open possible

• initiator waits for timeout before closing the connection (no packets arriving anymore…)

• congestoin indicated only by packet loss

• keeps buffers full

=> vulnerable to random packet loss

=> high latency

• applicatoin limited phase -> cannot send more data

  • => increases until amount of inflight = BDP

• Bandwidth limited

  • application could send more and bottleneck buffer is not yet full

• buffer limited

  • buffer is full and packets get lost, happens at amount of inflight = BDP + BtlNackBufSize

=> loss based operating poitn in amount inflight = BDP * BtlNckBufSize

=> delay based at point where BDP = amout of inflight (optimal point e.g. BRR tries to find)

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

• send with bottleneck bandwidth -> no queue can build up

• continuously monitors network to find minimal RTT and maximum bandwidth

• problem: cannot be measured at once

  • RTprop only if buffers are empty

  • BtlBw only if link is full utilized and queue starts growing

  • => solutoin : alternating measurements

• use filters to record those values against a sliding window

• startup

• drain

• probe bandwidth

• probe RTT

• similar to slow start -> double sending rate each RTT

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

• finds BtlBw in log2(BDP) RTTs

• can creaet query up to 2 BDP

• goal: remove during startup build up queqe

• -> drasticall reduce sending rate

• leave drain when data in flight matches estimated BDP

• periodically probe for more bandwidth

• BtlBw is estimated using max filter of about ten estimated RTTs

• sending rate = BtlBe * Pacing gain with pacing gian in [1.25,0.75,1,1,1,1,1,1]

• each step takes about one RTT

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

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

• probes all 10s -> if RTProb not measured in 10s, enter RTT probe mode

• ensure that all queues are empty -> reduce inflight to 4 segmetns for 200ms + RTT

• Problem: low delivery rate durign RTT probe -> performance drop…

• robustness against random packet loss

• low delay

• does not starve when copeting with other algorithms

Takeaways

• high potential to improve congestion control

• young and immature algorithm

• actively researched

• RTT unfairness

• bottleneck overestimation (inter-flow unfairness)

• inter-protocol unfairness

• inter-flow synchronization

• default max window size limits BDP

• window sacling option (negotiated during hanshake) allows window sizes up to 4GB

• => but problem remains: max number of unacknowledged data still limited by sequence numbers (32 bit)

• allow receiver to acknowledge ranges of segments

• => avoid unnecessary retransmission compared to cumulative ACKS

• => TCP option

• Stream Control Transmission Protocol (SCTP)

• Multipath TCP (MPTCP)

• Quick UDP Internet Connections (QUIC)

• TCP/UDP hybrid -> reliable, optional ordering, message oriented

• permits reliable unordered delivery

• other featueres: mutihoming, 4-way-handhake

problems:

• require changes in application implementations

• lack of support in middleboxes (NAT; firewalls,…)

• can use multiple interfaces/links simultaneously

• goal: improve resource utilization, throughput and reliablility

• mimics standared TCP, even offers fallback mode

• UDP based protocol that implements reliabilit, congestion control, multiple streams, encryption, etc.

• goal: reduce latency (compared to TCP+TLS)

• mimics UDP (middlebox support)

• receiver: directly forward segment to higher layer, even when buffer is not full yet…

• sender: send segment, even when buffer is not full yet

• wantso to measure throughput and thus, directly using the segments to measure things makes sense (no buffering, as it could influence the measurements)

• offload processing of packets / segments etc from the CPU to the NIC (network interface card)

• e.g. calculation of checksums…

• => advantages: e.g. in Gigabit ethernet, most of CPU workload would be made up of tcp traffic handling

• => also, PCI traffic gets reduced

• maximum length of packet capped due to MTU

• => reduce computational overhead caused by packet processing by aggregating multiple smaller packets into a bigger one…

• additional piece of hardware -> potential vulnerability that requires management and uodates…

• hardware limitations -> resource starvatino as less ressources avaliable than main sysetm

• probably proprietary hardware… -> effort to integrate it

• NIC can become obsolete quickly as technology progresses… => performance advances of main system render NIC obsolete…

• send several TCP and UDP packets

• -> chosen in such a way, that responses from different OS change and thus alow to compare response pattern to database of OS response patterns known before…

• -> e.g. options support, IP ID sampling, initial window size check…

• normal scan: open full conecitons (finish 3-way handshake) and then reset it

• stealth scan: only send syn flag and receive syn ack

=> answers:

• syn,ack -> port opened

• rst -> port closed

• no response / icmp unreachable -> port filtered (or assumed to be filtered by nmap at least…)

• stealt: requires sudo privileges and is faster / may not be logged due to no complete handshake

• normal : should usually only do if no root privileges, as higher chance of being logged and slower

• TCP saves by default several connection metrics -> cache when closing connection for next conneciton…

• => do not store them if one wants to measure things / create graphs to not have the measurement influenced by earlier conections…

=> contestion control is in general performed on the sending host…

• RTProp = minimum RTT over a certain time window

  • -> as the RTT does decrease with coongestion, the actual RTT is the smallest value measured…

• BtlBw = maximum deilivery rate over a time window

  • as the bandwidht gets reduced when the network is congested, the real bottleneck bandwisht is the maximum measured value…

• delta delivered / delta time

RTT:

• BDP as product of RTProp and BtlBw -> linear correlated to both…

Bandwidth

• BDP linear correlated -> if change in bottleneck link -> affects BDP only as long as it remains bottleneck…

• highly reduced bandwidht -> as always multiplicative decrease…

• no -> only with designated router (elected during hello with largest priority)

• -> handles building routing table and sharing with individual routers in area

• -> minimize communicatoin overhead…