CS 2204 Written Assignment Unit 6

1. Assuming standard 1500 byte Ethernet max payloads: how many IPv4 fragments will be
needed to transfer 2000 bytes of user data with a single UDP send? And, how do the 2000 bytes
get split over the frags?

IPv4 fragmentation is required when 2000 bytes of user data are sent over a single UDP transfer in a
typical Ethernet network with a maximum payload size of 1500 bytes. An IPv4 packet fragments, or
splits into smaller segments to enable transmission, when its size surpasses the network's Maximum
Transmission Unit (MTU).

In this instance, the data must be split into two IPv4 fragments because the payload of 2000 bytes
exceeds the maximum payload limit permitted:

1. Fragment 1: This segment contains the 1500 bytes maximum payload size that is permitted across
the network.
2. Participation 2: This makes up the final 500 bytes of data, making it the second IPv4 fragment
required to hold the whole payload.

The fragmentation procedure divides the payload into pieces of the right size that comply with the
maximum transmission unit (MTU) limitations of the network, hence guaranteeing the successful
transmission of the entire payload. After that, each piece is sent separately and put back together at
the recipient's end to create the original data payload.

2. Despite its conceptual elegance, RPC (Remote Procedure Call) has a few problems. Discuss
any 3 of those in brief.

- Security Vulnerabilities: RPC interfaces are inherently open, which makes them vulnerable to
security breaches due to a lack of strong authentication and permission procedures.
- Network Sensitivity: RPC systems depend heavily on the stability of the network; any problems,
especially in sluggish or unstable networks, can result in a reduction in performance or outright
failure.
- Error Handling Complexity: Resilient error management procedures are necessary to handle errors
in RPC, which can be challenging in distributed systems that are prone to multiple failures.

3. Why is timestamping needed in real-time applications? This is in the context of Real-time

Timestamping is crucial for real-time applications like Real-time Transport Protocol (RTP). It acts
as a pivot point for accurately distributing and synchronising real-time media streams. In order to
ensure flawless playing or display, these timestamps are essential for allowing receivers to recreate
the timing details of sent data. This ability to synchronise works with many streams and helps offset
network latency to provide a seamless and precisely timed experience.
4. Why does UDP exist? Would it not have been enough to just let user processes send raw IP
packets?

Compared to TCP, UDP is a simpler, connectionless protocol. It has less latency and overhead even
though it lacks some capabilities like congestion control and reliability. UDP, with its "best-effort"
delivery mechanism, avoids the complexities of connection maintenance, which makes it an
appropriate option for applications that value speed above unwavering stability. Allowing user
processes to directly send raw IP packets would be a more sophisticated option that could lead to
security flaws. Because of its abstraction, UDP successfully reduces these dangers and provides a
straightforward but effective communication solution.

5. Explain how QUIC eliminates a couple of RTTs usually needed at the start of a secure web
connection.

By combining the encryption setup and handshake, QUIC, or Quick UDP Internet Connections,
simplifies the first steps of a secure web connection. QUIC drastically reduces the amount of time
required and lowers latency by combining the traditional TCP handshake with TLS negotiation into
a single procedure. Notably, QUIC uses pre-established cryptographic data to provide a zero
Round-Trip Time (0-RTT) handshake. This novel method sets up following requests more quickly,
enabling more rapid and effective connection formation.

Reference

Coddington, B., Mayhew, S., & Lever, C. (n.d.). Remote procedure call over quic version 1.
https://www.ietf.org/archive/id/draft-cel-nfsv4-rpc-over-quicv1-00.html
Davie, B. (2022, October 7). Why Quic is not a replacement for TCP. The Register® - Biting the
hand that feeds IT. https://www.theregister.com/2022/10/07/quic_tcp_replacement/