Computer Networks Exam 2

Transport layer

Provides for logical communication between application processes running on different hosts

(Logical in the sense that application sees the processes as directly connected)

Only implemented in end systems

Network layer

Provides logical communication between hosts

User Datagram Protocol (UDP)

Transport layer protocol which provides unreliable, connectionless service (no handshake)

Delivers data from process to process

Provides integrity checking through the checksum field in the segment header

Unregulated, so no flow or congestion control

Transmission Control Protocol

Transport layer protocol which provides reliable, connection-oriented service (three way handshake)

Delivers data from process to process

Provides integrity checking through checksum field in the segment header

Provides reliable, in-order data transfer, flow control, and congestion control

Internet Protocol

Network-layer protocol which provides best-effort/unreliable delivery service

No guarantees or delivery, timing, or integrity

Socket

Door through which data passes from the network to a process or vice versa

Processes may have more than one of these

Demultiplexing

Receiver uses special header info fields to deliver segments to correct socket

Multiplexing

Sender handles data from multiple sockets and adds a transport header

UDP socket identification

(destination IP address, destination port number)

TCP socket identification

(source IP address, source port number, destination IP address, destination port number)

Web server socket methodology

Use one process and create a new thread with a new connection socket for each new client connection.

Frequent creating and closing of sockets can severely impact the performance of a busy Web server.

Benefits of UDP over TCP

• Finer application-level control over what data is sent, and when

  • Bypasses congestion control throttling and reliable delivery slow-downs

  • Good for real-time applications

• No connection establishment

  • Bypass connection delay

• No connection state

  • More active clients can be supported without the need for connection state

• Smaller packet header overhead

TCP connection state

• Receive and send buffers

• Congestion-control parameters

• Sequence and acknowledgment number parameters

TCP segment header size

20 bytes

UDP segment header size

8 bytes

Applications and protocols which run over TCP

• Electronic mail - SMTP

• Remote terminal access - Telnet

• Secure remote terminal access - SSH

• Web - HTTP/1 or 2

• File transfer - FTP

• Streaming multimedia - DASH

• Internet telephony

Applications and protocols which run over UDP

• Remote file server - NFS

• Web - HTTP/3

• Remote file server - NFS

• Network management - SNMP

• Name translation - DNS

• Internet telephony

UDP segment structure

• Source port #

• Destination port #

• Length

• Checksum

• Application data

End-end principle

Functions placed at the lower levels may be redundant or of little value when compared to the cost of providing them at the higher level.

Reliable channel

No transferred data bits are corrupted and all are delivered in the order in which they were sent

This service abstraction is implemented by a reliable data transfer protocol

RDT1.0 - Over a perfectly reliable channel

• Packet flow is only from sender to receiver

• Receiver side provides no feedback to the sender since nothing can go wrong

RDT2.0 - Over a channel with bit errors

• Bits in the packet may be corrupted but packets are in order

• Uses both positive and negative acknowledgements to signify what has been received correctly or incorrectly

• Retransmission required if incorrect

• Stop and wait protocol because the sender will not send a new piece of data until the receiver has correctly received the current packet

• Flaw: ACK or NAK may be corrupted

Automatic Repeat reQuest (ARQ) protocols

Reliable data transfer protocol based on retransmission

Require:

1. Error detection

2. Receiver feedback

3. Retransmission

RDT2.1 - Solution for rdt2.0 corrupted ACK or NACK

Alternate solution:

• Sender requests repeated reply from receiver

  • Request may also be corrupted

• Add enough checksum bits to allow the sender to detect and recover from bit errors

Implemented solution:

• Sender resends the current data packet when it receives a garbled ACK or NAK packet

  • Introduces duplicate packets into the sender-to-receiver channel

  • Add a sequence number field which the receiver can check to determine whether or not the received packet is a retransmission

    • 1-bit sequence number suffices in stop-and-wait protocols

RDT3.0 - Over a lossy channel with bit errors

• In addition to corrupting bits, the underlying channel can lose packets as well

• Approach to solve this is for the sender to choose a time value such that packet loss is likely, although not guaranteed to have happened

• After counter timeout, packet is resent

• If duplicate packets are sent, the receiver will detect this based on the sequence number

• Also known as the alternating-bit protocol

RDT2.2 - NAK free

• Instead of sending a NAK, send an ACK for the last correctly received packet

• Duplicate ACKs signify that the receiver did not correctly receive the packet following the packet that is being ACKed twice

Pipelining

Sender is allowed to send multiple packets without waiting for acknowledgements

• Range of sequence numbers must be increased

• Sender and receiver sides of the protocols may have to buffer more than one packet

• Pipelined error recovery required

  • Go-Back-N

  • Selective repeat

Go-Back-N (GBN) protocol

Sender is allowed to transmit multiple packets (when available) without waiting for an acknowledgement but is constrained to have no more than some maximum allowable number, N, of unacknowledged packets in the pipeline.

• N referred to as the window size

• GBN protocol is a sliding-window protocol

• If there are not N outstanding, unacknowledged packets, sender can send

• ACKS are cumulative, indicating all packets up to its sequence number have been received

• For lost or overly delayed packets, a timeout will occur and the sender will resend all packets that have been previously sent but not acknowledged

• Timer times the oldest transmitted but not yet acknowledged packet

• Receiver discards out of order packets and ACKs for most recently received in-order packet

• Single packet error can cause a large number of packets to be retransmitted

Selective repeat protocol

Avoids unnecessary retransmissions by having the sender retransmit only those packets which were received in error (lost or corrupted) at the receiver

• Windows size N limits the number of outstanding, unacknowledged packets

• Sender will have already received ACKs for some of the packets in the window

• Each packet must have its own timer, since only a single packet will be transmitted on timeout

• Receiver ACKs and buffers out-of-order packets within the receive window until missing packets are received

• Receiver acknowledges received packets with sequence numbers below the current window base to move the sender window forward

Packet reordering

Channel can be thought of as essentially buffering packets and spontaneously emitting these packets at any point in the future.

Ex. an old copy of a packet appears even though neither the sender or receiver window contains it

To guard against duplicate packets and their reused sequence numbers:

• Ensure that a sequence number is not reused until the sender is “sure” that any previously sent packets with sequence number x are no longer in the network.

• Done by assuming a packet cannot “live” in the network for longer than some fixed maximum amount of time.

TCP connection

• Full-duplex service

• Point-to-point, between a single sender and a single receiver

• Three segments are sent to establish the connection, known as three-way handshake

Maximum segment size (MSS)

The maximum amount of data that can be grabbed and placed in a segment

Does not include the TCP/IP headers

Must fit in MTU

Has typical value of 1460 bytes

Maximum transmission unit (MTU)

The length of the largest link-layer frame that can be sent by the local sending host

Includes TCP/IP headers

Ethernet and PPL link-layer protocols have ___ of 1500 bytes

TCP header

• Source port #

• Destination port #

• Checksum

• Sequence number

• Acknowledgement number

• Receive window

• Header length

• Options

• Flag

• Urgent data pointer field

TCP sequence number

The byte-stream number of the first byte in the segment sent to a host

TCP acknowledgement number

The sequence number of the next byte which the Host A expects to receive from Host B

Exponential weighted moving average (EWMA)

More weight is placed on recent samples than on old samples.

The weight of a sample decays exponentially fast as updates proceed

TCP fast retransmit mechanism

The receipt of three duplicate ACKs for a given segment serves as an implicit NAK for the following segment, triggering retransmission of that segment before timeout

The sender will receive the original ACK for the last received data and then three additional ACKs for the same data (there is a gap and the new data is not what is expected)

TCP selective acknowledgement

Allows a TCP receiver to acknowledge out-of-order segments selectively rather than just cumulatively acknowledging the last correctly received, in-order segment

TCP flow-control service

Eliminates the possibility of the sender overflowing the receiver’s buffer.

Matches the rate at which the sender is sending against the rate at which the receiving application is reading.

TCP receive window

Gives the sender an idea of how much free buffer space is available at the receiver

LastByteRcvd - LastByteRead <= RcvBuffer

rwnd = RcvBuffer - [LastByteRcvd - LastByteRead]

Sender tracks that in order to not overflow the rwnd:

LastByteSent - LastByteAcked <= rwnd

When rwnd is 0, sender must continue to send segments with one data byte until an ACK returns with a nonzero rwnd value.

Establishing a TCP connection

• Client sends TCP SYN segment

• Server allocates buffers and variables and sends a connection-granted, SYN-ACK segment

• Client allocates buffers and variables and acknowledges the server’s connection-granted segment

Fast open/ 0-RTT handshaking

A cookie is provided by the server to the client

It encodes all the connection information needed in a future connection

Closing a TCP connection

• The client sends a special TCP FIN segment

• The server sends an ACK segment

• The server sends a TCP FIN segment back

• The client sends an ACK segment

All buffers and variables are deallocated

SYN flood attack

A Denial of Service attack where attackers send a large number of TCP SYN segments without completing the third handshake step

The server’s connection resources become exhausted as they are allocated but never used for half-open connections

Costs of congestion

• Increased queuing delay as the packet arrival rate to a congested link nears its capacity

• Decreased application-to-application throughput due to the presence of retransmitted packets

• Potential for congestion collapse

Goal of congestion

For N connections, set their transport layer’s sending rates so that their aggregate sending rate is close to, but does not exceed, the bottleneck link capacity

End-to-end congestion control

Congestion must be inferred by the end systems based only on observed network behavior (ex. packet loss and delay)

Network-assisted congestion control

Routers provide explicit feedback to the sender and/or receiver regarding the congestion state of the network

Congestion window

Imposes a constraint on the rate at which a TCP sender can send traffic into the network

The sender’s send rate is roughly cwnd/RTT bytes/sec. By adjusting the value of cwnd, the sender can therefore adjust the rate at which it sends data into its connection.

TCP maximum amount of unacknowledged data at sender

LastByteSent - LastByteAcked <= min{cwnd, rwnd}

TCP congestion control

Infers congestion based on a loss event

Self-clocking because it uses acknowledgements to trigger/clock its increase in congestion window size

Classic TCP congestion control - Slow-start state

The value of cwnd begins at 1 MSS and increases by 1 MSS every time a transmitted segment is first acknowledged.

Results in a doubling of the sending rate every RTT

Starts slow but grows exponentially fast

When congestion is detected:

• Sets cwnd value to 1 MSS

• Sets ssthresh to cwnd/2

• When ssthresh is equal to cwnd ushers in the next state

Classic TCP congestion control - Congestion-avoidance state

Increases the value of cwnd by just a 1 MSS every RTT

When congestion is detected:

• Timeout-indicated loss

  • Sets cwnd value to 1 MSS

  • Sets ssthresh to cwnd/2

• Triple ACK loss

  • Halves the value of cwnd + 3 MSS

  • Sets ssthresh to cwnd/2

TCP congestion control - Reno fast recovery

After triple duplicate ACKs, reduces the congestion window and recovers without resetting to 1 MSS as a timeout would

TCP congestion control - Cubic

Uses cubic window growth around the window size at a previous congestion event, increasing cautiously near that earlier size

TCP congestion control - Bottleneck bandwidth and RTT

Uses estimates of bottleneck bandwidth and minimum RTT to keep the path busy while limiting persistent queue buildup

TCP congestion control - Vegas: Delay-based

Uses measured RTT delay to proactively detect congestion onset, hopefully before packet loss occursT

TCP congestion control - Tahoe

Cut its congestion window to 1 MSS and entered slow-start phase after either a timeout-indicated or triple-duplicate-ACK-indicated loss event