The basic definition of network is a system of links (or channels) that interconnect nodes (or peer entities) in order to move information between them.

Obviously lots of different networks but we will largely speak about the internet.

• Ties together 20,000+ ISP networks
• Uses the IP protocol to do the tying of different networks.
• It is bloody huge, with a huge range of technologies involved
• We know all of the other problems (failures, trust etc)

Bandwitch/Capacity - is the width of the link, number of bits and sent/received per unit time (bits per second)

Latency/Delay - is the 'length' of the link, propogation time to travel along the link (seconds)

Bandwidth Delay Product - is the 'volume' of the link, amount of data that can be in flight at a time (undefined, bits)

It gives the maximum amount of data that can be transmitted by the sender at a given time before waiting for acknowledgment: it is the maximum amount of unacknowledged data.

Packet delay - time it takes for an entire packet to travel from A to B.

Packet Delay = Transmission Delay + Propogation Delay = (Packet Size/ Bandwidth) [How long it takes us to put the independent packet in the link] + Link Latency [How long it takes 1 bit to travel a link]

Jitter: is the variation in the time between data packets arriving, caused by network congestion, or route changes

Pipe View: Diagramatic view of packets in a link

>

• y: Bandwidth, x: Time
• <img src="/notes/typora-user-images/Screenshot 2021-01-22 at 17.51.53.webp" alt="Screenshot 2021-01-22 at 17.51.53" style="zoom:50%;" />
• Top Bracket: Packet transmission time
• Arrow: A packet, a unit of data to make transmission 'easier'
• The length of the pipe indicates its latency.

But it isn't that easy, we can't have EVERY node having a direct link to EVERY other node, so we need some smarts - switched networks. We have a box (a switch) sitting in our graph moving the data around.

Circuit switching - a source node reserves capacity along a path to the destination node, it then has sole use of the link so ends data when it wants and tears down the link at the end. This can be improved with:

Frequency Division Multiplexing ( means sharing physical resource) - users have less bandwidth because they split the channel into multiple frequencies (radio stations)

Time Division Multiplexing - users have full bandwidth, but can only transmit at certain points (their slot). Time is divided into frames (a full sequence of senders) which go into slots (each sender has one slot):

x: Sots

Top arrow: empty slots are wasted capacity

Bottom arrow: slots are at recurring time.

😊 guaranted performance + fast transfers over dedicated link

😔 wastes bandwidth if traffic is bursty (not a continuous stream, send-wait-send...)

😔 connnection setup (reserve and teardown) is overhead for small changes

😔 recovery from failure is slow as it needs to RESERVE a new link if the current one dies

eg POTS: Plain Old Telephone System

Packet switching - data is sent as chunks (packets) with a header (telling the network what to do with the packet) and a payload (data). We then get switches to forward packets to the 'right' place to go based on their forwarding table.

Connectionless assumptions of a packet-network (packet goes out automatically without determing whether the receiver is ready, or even whether a receiver exists)

We almost always assume switches are store and forward so they receive a packet in full before sending it on (this means we can use checksums etc).

The other option would be cut through switch which sends as data comes in (as the header comes first and tells us where next) BUT this is rarely used.

We don't reserve link capacity in advance so we leverage statistical multiplexing - means we can have multiple links sending data and we can handle it. Because:

we share our link OVER TIME, but data is transmitted based on demand rather than predetermined time step.

When data is there to be sent we send it. This works pretty well when traffic is bursty (connections sending at different times).

But at some point we will get data in from two places, at which point we get transient overload and we use a queue/buffer to store packets while we wait to be able to send them the buffer absorbs changing rate of transmission.

However with persistent overload we will fill the buffer and end up dropping packets.

This queuing means we have queuing delay caused by packet interference (when the network is busy our packet goes slower)

• Our key number is undefined: L is packet length, a: average packet arrival rate, R: bandwidth = Traffic intensity
• Traffic intensity approx 0 undefined small queuing delay
• Traffic intensity closest to 1 undefined large queuing delay
• Traffic intensity > 1 undefined infinite queuy delay (drop packets) as more data arriving that can be handled

😊 Pretty much all the cons of circuit switching: no wasted bandwidth, no setup overhead, resilient

😔 No guaranteed performance due to queuing delays

😔 Send extra information (headers)

Circuit switching: has a set number of max users simultaneously (total link size / bandwidth per person needed), so even if users barely need a link, they still stop other people using it.

Packet switching - has no set maximum, but we can calculate the probability of the link being overloaded:

Using a binomial distribution: n is number of users we WANT. p is probability of user being active at any time.

Overloaded number (k): number of users who would have to be active to overload network

undefined

The activity chance follows the law of large numbers (we have a big enough sample). The central limit theorem is valid aka the traffic characteristics are normal. ON-OFF periods are normally distributed

Bursts of traffic activity, packet-bursts, similtaneous bursts of traffic exhibit heavy-tails and are not normal.

Results in RTT computation that provides a smooth, continuous response.

Traffic may be synchronised – either overtly (router-update example) or accidently (packet loss at the same buffer. (Each users being active is independent.)

creating synchronised loss and retransmission events where the flows themselves are not independent.

Centralised multiplexing

coordinating how the different nodes share the physical resource with knowledge of flows, e.g. queue lengths (for variable-rate flows) and priorities, can maximise channel usage (consider static real-time scheduling)

also no latency when making a centralised (local) decision (compared to CSMA/CD when we might need to retry).

however requires a centralised scheduler - a central “point of decision” having both control over multiplexing and the required flow-specific knowledge

The internet has tier of ISP's

• Tier 3 and Local ISP's - these are the last hop of bits in the network, they are customers of the higher tier ISP's.
• Tier 2 - these are regional and are customers of Tier 1, but also do peer-to-peer with each other privately.
• Tier 1 - the backbone of the internet which have wires worldwide.

How to build an internet cake

We use the concept of abstraction to split the internet (just a big computer system) into modules, unsuprisingly there are positives and negatives. We say we divide the system into layers where:

Interaction only happens between adjacent layers (in the same system)

Bottom layer is physical media

Top layer is application

Entities (a layer in one system) communicates with its peer entities, this is supported by the layers below it.

OSI Model

Application: The thing

Presentation: Allow applications to interpret meaning of data (encrypt, compress).

Session: Tracks dialog between computers as sessions

Transport: (Un..) reliable transport

Network: Best effort global packet delivery

Data link: Best effort local packet delivery

Physical: Physical transfer of bits

Actual Internet: {from OSI}

Application {Application/Presentation/Session}: SMTP/HTTP/DNS

Transport {Transport}: TCP/UDP

Network {Network}: IPv4, IPv6

Data link {Data link}: Ethernet, 802.11

Physical {Physical}: Copper, Fiber, Radio

We implement layering via embedding:

Basically high-layer info is embedded with lower layer info.

We can partly decode in transit to figure out something in the switch/router.

In these layers we have protocols, we say that in order for entities to communicate they must speak the same protocol (& version number). So the protocols are standardized, so that this can happen. The intermediate layers between application and physical layers gives us abstractions to make life easier.

😊

Modularity hides underlying detail/complexity

Innovation in different layers can proceed in parralel.

Applications only need to understand a couple (TCP, UDP) of transport mechanisms to work.

Networks using different lower-level protocols can communicate (primarily with IP)

😔

Layers may duplicate functionality

There are layer violations (layers doing too much) when gains are large (TCP-over-wireless) or when no trust (Firewall)

Information hiding can hurt performance: TCP doesn't get get told WHY a packet was lost: corruption vs congestion.

Headers can get bigggg.

But overall the layering approach is the reason the internet exists

End-to-end principle is massively cited/debated but broadly means that implementing functionality IN the network does not mean we don't do the work in the ENDS as well. There are two interpretations from this:

Only if sufficient - only implement functionality at lower levels if it can be completely implemented at this level:

if we can stop the hosts doing work at a lower level, then do so, but if host will still have to do work then DONT.

Only if necessary - Don't implement anything in the network that can be implemented correctly by the hosts. We make the network layer minimal so the system remains more flexible.

Only if useful - Only implement functionality at a lower layer if there is performance enhancements when using the functionality AND when applications don't use it.

End-to-end vs hop-by-hop

hop-by-hop, do everything at every hop

hop-by-hop encipherment is a necessary but insufficient condition for safe/secure data

hop-by-hop can not ensure a web-page will not be intercepted however wifi security modes such as WEP/WPA/WPA2 help - as does 802.1x by ensuring all traffic (in wireless) is enciphered at least in the wireless/eduroam domain, thereby preventing trivial interception.

end to end do as little as necessary in the network - push functionality to the ends.

end-to-end ensures secure carriage between client and server; however it removes the ability for the network to optimise carriage (no caches work)

end-to-end is expensive but can ensure your website order / credit card is not readable from any intermediate systems.

Makeup of a network:

Hosts - implement the full stack, they are bits on the wire all the way to the application layer.

Router - participate in global delivery, so must read up to the IP layer to know what switch to head to next.

They don't support reliable delivery as they have do nothing with Transport Layer.

Switches - only participate in local delivery, so read the data link layer to find the next switch to send to.

There are alternatives to standardisation eg C:

>

• Only have one implementation of the thing, and everyone use it e.g. Java
• Have open-source projects to create the implementation e.g. Python
• Sole-sourced implementation.

The Data Link Layer: Layer 2

Where a packet is called a frame, which encapsulates a datagram by adding a head & a trailer. It gives:

Physical addressing

Reliable delivery between adjacent nodes

Flow control

Error Control

Access control

We implement the link layer in adaptors or Network Interface Cards; which attach into the host system.

Line coding

Is how we convert binary to voltage patterns:

Non-Return-To-Zero: the simplest technique forces high if 1 and low if 0

😔 Long stream of 0's/1's causes baseline wander

we measure what is 0/1 from an average of the signal, so with lots of a signal value our baseline changes

😔 Long stream of 0's/1's causes clock drift

we haven't got enough transisitions to resync/recover the clock

Non-Return-to-Zero-Mark: a 1 causes a transition (from either direction), 0 means do nothing

Non-Return-to-Zero-Inverted: same as NRZM but transitions exactly on the 1 (in the middle of the signal being held).

Differential Manchester: use a clock and XOR NRZ and clock together, where each clock cycle is 1 bit (full up and down)

😔 Our bit-rate (rate of actual data transfer) is half our Baud rate (number of hi/lo's sent) as we sent two levels per 0/1

NRZM/I has the same problem as NRZ wtih clock drift as we could still see few transitions, so we use block coding to make sure there are always some exchanges (not lines of 0's or 1's). We turn any 4 bit symbol into a 5 bit symbol with a magic table, then code that with line coding. This is most commonly used as 8b/10b codec so every byte is turned into a 10 bit string with transitions to then be coded.

This could also be done with line code scrambling statistically (to get lots of 0's/1's) choose a string of bits which both parties know, then XOR it with the data before sending. XOR is symmetric so we XOR the sent data to get the actual data.

Note this doesn't provide secrecy but can be combined with block coding to give the idea of framing (start/end of a frame)

Perfect signal do not exist: problems cause bits to flip:

Attenuation - loss of energy in signal

Distortion - signal has its form changed

Noise - all sorts of different noise

We send symbols on the wire which represents data. Normally we just have hi/lo for 1/0 but we can increase the number of symbols using quad level code (0, undefined, undefined, 1) corresponds to 00, 01, 10, 11), this could increase our bit rate (data transfer speed) if our baud rate (symbol transfer speed) stays constant.

Error detection

add a parity bit - every undefined bits we add a parity bit such that there is an even number of 1's present, then when receiving we spot errors when there is an odd number of 1's

😔 doesn't work for two-bit errors; to make it sueful we need a lot of extra bits

cyclic redundancy check - every undefined bits we add a CRC(undefined)

😊 can detect multi-bit errors

😔 doesn't fix errors

Action: For both of these we can detect errors then ask the sender-to-send again

Error correction

Parity bit grid - sort the bits in a grid, have parity bits for each column AND row, then for single bit error, we find the problem bit as one column and row will both be wrong.

Forward error correction - assign only some bit sequences as valid (as far away from each other as possible) then when we get a 'bad bit sequence' find its closest error-free data (where distance is number of bits needing to change) and fix it.

Multiple access protocol

An algorithm distributed across nodes to decided how they share (the medium - eg WiFi or Ethernet), and where the medium is their ONLY coordination method. (example was CDMA)

Ideal Protocol:

when one node wants to transmit its ends at rate undefined

when undefined nodes want to transmit each sends at rate undefined.

Fully decentralised so no clocks etc

Channel partitioning:

Time Division Multiplexing and/or Frequency Division Multiplxesing but now called Time Division Multiple Access & Frequency Division MA.

😔 we get wasted bandwidth/time 😊 is fair

CMDA: Code Division Multiple Access

This is another multiplxing scheme which is used in shared mediums (3G etc)

We assign a unique code/chipping sequence (must be orthogonal) to each user, and each user encodes their data by XOR'ing the chipping sequence with the data. Decoding is then the opposite.

The technique allows for multiple users to transmit simultaneously on the same frequency.

What does the data look like?

How is data bit and code combined?

How is channel output decoded?

How does it work with the multiple senders and single channel link ?

How does decoding differ?

Taking turns (Bluetooth, IBM Token Ring)

Polling - some master invites shares to submit data, and they do. The master polls the slaves.

😔 Polling overhead + lots of latency - single point of failure

Token passing - we pass a control token around, saying who's allowed to speak at any moment

😔 Token overhead + lots of latency + single point of failure (from losing token)

😊 gives bounded latency

Asynchronous Transfer Mode - we have slots like Time Division MA, but anyone can send at any time, they just attach 'who they are' as a header

😃 variant of packet switching

😔 virtual circuits need setting up undefined OVERHEAD

Random access - basic concept is when node has packet send it, when there are multiple nodes transmitting stop & wait.

we are broadcasting rather than point-to-point so can get collisions when a node is trying to receive multiple signals simultaneously -> neither signal gets heard.

Needs three ideas:

Carrier sense - listen before sending and don't interrupt if channel is busy

Collision detection - if two users start simultaneously stop and have another go later.

Randomness - determine the later in some random fashion, so you don't re-collide.

Chosen solution in wired connections is: Carrier Sense Multiple Access/Collision Detection (CSMA/CD)

We encorporate carrier sense and collision detection together

carrier sense isn't enough due to propogation delay

this is easy in wired connections but hard in wireless

When a collision is detected we STOP and try again later this avoids wasted time in garbage signals.

😔 the time for collisions to be detected can be upto undefined where undefined is time to travel between nodes, this can waste a LOT of time

performance (efficency): Time spent transmitting packets undefined Total time

undefined: packet size

undefined: bandwidth

undefined: constant about how many collisions

undefined: distance between two nodes

so large packets, small distances undefined performance undefined 1

but when we increase bandwidth undefined network 'fully used' less

because of this equation high speed networks have switches to REDUCE undefined.

The random access bit is done with: exponential backoff, after m^th^ collision:

choose k randomly from {0, ..., 2^m^ - 1}

wait (K \* slot size) before trying again.

min packet size used as slot

Ethernet Frame Format

A lot of what we've been speaking about is encorporated into some version of Ethernet it can be used on all sorts of cables, network setups and medias. The exact thing that is implemented depends on version but the common attributes:

Preamble: white noise to synchronise clocks

Destination MAC address: 48 bit addresses has no 'proper' structure, but are globally unique (probably) and don't normally change

Source MAC address

Type

Payload

CRC: error detection

Pairs of twisted cabling is a single connection. (coaxial/fibre)

802.11 (WiFi)

The basic idea is that we have access points set to a specific channel, which broadcast their Service Set ID (SSID) and MAC address periodically. Then hosts scan for access points and send them stuff.

One of our key problems is that collisision detection is really hard, because we can't listen and send simultaneously and a sender signal is far less likely ot be correct.

If we try and do normal collision detection we have two problems:

Hidden Terminals

A is hidden from C so neither realises they have caused a collission at B.

Exposed Terminals

C sees that B is sending to A, so decides not to send to D, even though it could do.

Key issues are:

There is no concept of a global collision; everyone reaches different people.

Collisions occur at the receiver not the sender and we only care about what receiver can hear not sender.

Wireless CSMA - (collision avoidance)

CA (collision avoidance):

Our carrier sense is still similar to collision detection, if the medium is busy wait a random time) rather than keep checking) but other than that no change.

We infer collisions from the (lack of) receipt of an ACK from a receiver.

On collisions we use exponential backoff to adapt contention window (avoid having contention again)

😊 Fairly low latency and little wasted bandwidth with low collision probability

😔 doesn't work well with hidden terminals still

when the hidden terminal sees an ACK it doesn't know if transmission is done.

RTS/CST:

Method

Sender sends a Request to Send frame with the length of the transmission

Receiver responds with a Clear to Sender frame

Sender sends data

Receiver sends an ACK

Situations

When sender doesn't get CTS back, assume collision and backoff

If a node hears RTS, but not CTS - send data as the relevant receiver is not in range of our node, so can send

If a node hears a CTS - stay quiet until you hear an ACK

😊 good for high-traffic Access Points and helps with hidden terminals problem

😔 slower than standard CA (but could be turned off dynamically).

Channels: another technique for avoiding wireless collisions

split our frequency band into channels which don't interfere with each other

so two nodes in some range won't interfer with each other (if they choose different channels).

For Wifi:

we split into 14 overlapping channels, but there are 3 completely separate channels - 1, 6, 11.

but other technologies already share some of WiFi's frequency space so cause interference eg Zigbee.

The hardware: behind the data link layer

Hubs - dumb physical repeater; bits come in from one node and hub sends out bits to everyone else. NOTHING SMART, no CD etc.

Switch - smart link layer device takes active role and selectively forwards frames to correct place based on MAC address and Switch Table.

They are transparent (hosts unaware of presence) and self-learning (they figure out MAC addresses as they go)

It allows us to connect different physical media as it needs to do conversions between different media protocols.

Our aim is to make a switch table with each entry containing

MAC address of host

Interface number to reach host: which 'wire' to send stuff down

Time to Live: how long entry lives

Approach

Firstly we say that EVERY packet received we record MAC address and interface number.

Then to find new MAC addressses we flood "who's MAC address is this?"

Wait for a response

😊 this works with connected swtiches as well, so every switch has a table of the next step for ALL hosts.

😔 problems when we have loops!

Solution: to loop problem!

create a spanning tree: a sub graph connecting each vertex WITHOUT ANY LOOPs, if a link is not in spanning tree, we won't use it.

Each switch determines if each interface is on the shortest path from the root i.e not in the spanning tree.

distributed minimum spanning tree algorithm:

send messages of form (Y, d, x)

Y: proposed root

d: distance to root

x: node message came from

everyone proposes themselves as root: (X, 0, X)

arbitrarily decide root based on lowest ID

switches constantly receive messages and will change their distance (and flood everyone else) if

message has lower root ID than current choice

message has shorter distance to some root

algorithm must react to failure:

root switch periodically annoces itself as root (and propogate around tree).

other switches detect failure through timeout and claim to be root if they think failure has happened (algorithm completely starts again)

Local networks can't be too big as:

creating MST's is hard for larger networkers

every switch knows the location of every other host - BIG tables.

The Network Layer

Aim: Produce a global system with its own addresses: building on top of the data link layer - which was fundamentally LOCAL.

Router: the tech that operates on the network level.

It does two jobs at different timescales:

Forwarding

we direct a data packet to an outgoing link based only on the individual router state (a forwarding table).

this has to be very fast

Routing

we compute the paths packets will take and generate the individual router state based off of conversations with other routers.

This can afford to be slower as we shouldn't have to do this too often.

Router Capacity = N (Number of external router paths) x R (Speed/Line Rate of a port)

We normally assume ports are full duplex so routers can send & receive simultaneously along the path.

Inside our router:

Data plane

Linecards (input)

process packets on their way in and strips away ethernet frame to get bits of the (IP) packet and make forwarding decisions.

they also manage queues and each have their own foorwading table.

Interconnect Fabric

basically does what linecards want, and moves packets between linecards.

Linecards (output)

repackage packets as ethernet frames and send on its port.

Control plane

Route/Control Processor

makes decisions over a long time, it create the forwarding table and pushes it to EVERY linecard (input) simultaneously.

Routing: control plane

We split the internet into Autonomous Systems/Domains and manage routing at two levels:

Intra-Domain routing - each domain chooses its routing protocol to route packets around its own domain (each domain is controlled by one admin).

Inter-Domain routing - the common protocol to allow domains to speak to each other, we use Border Gateway Protocol (it allows companies to do as little comms as possible), but we won't cover that in this course 😃.

The actual preference becomes "whatever BGP considers best" so it may pick either solution.

Devolves a BGP routing solution problem to a Longest prefix match problem. LPM always wins.

Local, short path routes for a particular IP prefix are injected into the local BGP routes. These cause IP traffic for an address in that prefix to be routed to a locally designated destination.

Can also us Content distribution system specialist DNS – useful when there is no local datacenter.

Implement netblock filtering to restrict the size of the routing table.

The whole concept of routing protocols: is that each router calculates its own routing table by treating the network as a graph where edges have an associated "cost" (which is some number/function of distance). They want to find the last cost path from A to B.

multi homing allows devices to be on multiple networks but this increase the routing table size.

Intra-Domain routing algorithms

Link State

Each node maintains its local link state (a list of directly attached nodes + cost).

Each nodes floods its local link state, and nodes learn the global link state and forward on the information.

Each node knows the whole graph, so computes Dijsktra to find its shortest path to every other node (<u>each iteration we find one more closest neighbour, so we have to do undefined iterations!</u>) then its forwarding table comes from this info (just the first hop needing to be done).

😔 scalability

we need to send undefined messages to discover global state.

every node has an undefined (can become undefined) operation to compute Dijkstra.

Dijkstra you explore the best node possible from you're current frontier.

Keep a stack on the left to show order you explored.

our link state database in each node is undefined

we have undefined entires in our forwarding table

😔 transient disruptions

failures result in some routers knowing before others so the link-state DB is inconsistent.

this can lead to forwarding loops of nodes thinking the other is the shortest path, so goes back and forth.

Distance Vector

Every node maintains a distance vector of how far away from EVERY other node it is.

It shares this with its neighbors.

On receiving a distance vector a node compares it to their current distance vector and updates any entries that are shorter (with a note to say where to send it).

This iterative process means nodes converge to the set of shortest paths by only knowing hte NEXXT node that it needs to send to.

😔 using a non-additive metric (eg maximal capacity of link) - we get a problem with looping as the 'cost' won't necessarily change in a loop, so we keep going looking for the best.

😔 routers use different metrics - if nodes care about different things their distance state vector will have different meaning to different nodes, this is a problem.

😔 routers can lie - either on purpose or not, we can get ALL traffic going through one router because it says its next to EVERYTHING.

😔 Overall it is more vulnerable to loops

😊 It has 'good' complexities

#messages = undefined

where #iterations is ideally undefined but varies due to routing loops or the count-to-infinity problem: nodes feed each other bad information due to a failed node and distance to failed node keeps increasing.

poisoned reverse we advertise undefined to the mutual node.

processing = undefined

Metrics for routing:

Propogation delay

Congesiton

Load balance

Bandwidth (available, capacity, maximal)

Price

Reliability

Loss rate

Combinations

Message delivery types:

Broadcast: send message to everyone

Multicast: send message to all members of some group

Anycast: send message to any members of some group.

Datapath

will keep working even when control plan is broken (it will keep using most recent table update).

per-packet delay: undefined (how to speed up)

typical values

RTT is .15s and BW 100Mb/s

for a LAN link

queueing ≫ propagation ≫ transmission ≫ processing

for a Data Centre link (unusually large b/w but bound (small) RTT values)

(queueing) ≫ transmission ≫ propagation ≫ processing

absurdly low latency and large bandwidth: undefined, 10 Gb/s such that actually bandwidth delay product much lower.

implementations: some of the considerations in DCN include practical circuit-orientated networks, with the lowest layer having no switches or queues.

the cause of propagation (proportional to distance)

the cause of queueing (proportional to contention)

the cause of processing (unusual packets)

the cause of transmission (the capacity of the link)

processing delay: time required to examine a packets headers and determine where to direct the packet.

use circuit switching (however needs reservation of link etc)

simple deltas on the amount of processing per packet

can include e.g., bit-level error checking (which you could remove)

queueing delay: packets experience the queueing delay as they are stored in queues awaiting transmission onto the link. The delay depends on the amount of congestion and length of queues.

accept more occasional loss with smaller queues

range from 0 (or negligible) to undefined scale values, undefined, but use number of packets and buffer story to calculate.

transmission delay & propagation delay already discussed.

per-packet processing:

accept packet arriving on link.

lookup packet destination in forwarding table: speed-limit on the operation: a naive forwarding table for a 32 bit address would have 4 billion entries!

we group entries to keep table size small

implement Longest Prefix Match by ordering the entries from most to least specific then searching downwards. That way the first matching entry we find will be the most specfic - we should choose Cmabrdige rather than England.

Exception processing requires that a packet be sent to a control processor causing significant additional delay - the control plane much slower and will also take up transfer time.

manipulate packet header eg decrement Time to Live

send packet to outgoing port.

buffer packet in the queue: need to decide how big to make our buffers: based a lot on TCP as this is a majority of the traffic

Def: T (RTT: Round trip time) - C (capacity) - W (window size)

Row 1: This is huge and present loads of problems: big buffer undefined longer queuing time as use slower DRAM.

Row 2: Can use SRAM feasibly. Basically says the peak sawtooth won't be reached by everyone simultaneously, we're more likely to have a fairly flat line.

Row 3: If access network is slower than the backbone this makes sense.

transmit packet

IPv4: the de facto transport layer for the internet

Structure

Version number: necessary so we know what else to expect

Header length: number of 32-bit words in the header typically 5

TOS: allow packets to be treated in different ways, v complex, largely ignored

Number of bytes of packet: max size in theory is (2^16^ - 1) but Ethernet frame has smaller max

2nd row: used for fragmentation if packet too big later xx.

Time To Live (TTL): Decremented at each hop and discarded if reaches 0: Time exceeded ICMP (Internet Control Message Protocol) message sent when TTL=0

Protocol: Identifies the higher level protocol: 6 is TCP; 17 is UDP

Checksum: check if the header is correct: if it is wrong router discard it. Recalculated every router.

Source: useful for reply mechanices and acceptance decisions.

Destination: get there! Allows node to make forwarding decisions

Options: asks routers to do some extra work

Fragmentation

When forwarding a packet an internet router can split it into pieces for the next hop, this is needed as network links Maximum Transfer Units - which is the largest possible data-link frame. This changes as we travel as different technologies have different capacities.

We then reassemble at the final destination, even if fragmented multiple times.

Structure:

The identifier (16 bits) are used to tell which fragments belong together.

The flags (3 bits) have:

Reserved (RF)

Don't Fragment (DF) - tells routers to not fragment, they instead DROP the packet and send back "Too large" ICMP message.

More (MF) - says that this fragment isn't the last one from the original packet.

The offset (13 bits) is used to say which part of the original datagram the fragment covers in 8 byte units.

Addressing

An IP address is 32 bits long in the form 128.12.3.244.

We assign an address to each interface (connection between computer and physical link).

Generally hosts have one interface, whereas routers have multiple.

Subnets are groups of interfaces

the first part of the IP address is the subnet part

the second part is host part

/24 in the address: is the subnet mask: that tells us how many bits are 'subnet'.

Devices in a subnet can interface with each other without a router intervening

e.g: subnet[223.1.2].host[3]/24

We use Classless Inter-Domain Routing:

we AND the subnet mask (a bunch of 1's) with IP address to get the subnet address.

we get IP address by:

Hard coding it in a system admin file.

Dynamic Host Configuration Protocol - we dynamically ask for an IP address from a server and it gives us one.

this means a network can reuse IP addresses when computers are turned off.

the server knows addresses its allowed to allocate by being told by ISP's who get told what they can allocate by ICANN. Noe the hierarchical organisation makes routing easier in the form of adverts by ISP's saying "send me anything with addresses xxx".

special addresses:

0.0.0.0/8 - labels the current network (to be used as source address)

10.0.0.0/8 - used for local communications within a private network

127.0.0.0/8 - used for loopback addresses/localhost, connecting to itself.

192.0.0.0/24 - used for private network

20.3.2.0/24 or 20.3.0.0/16 - looks like a subnet mask is the network identifier

20.3.2.255/24 or 20.3.255.255/16 - subnet then all 1's is the broadcast address

192.108.1.1/24 or 192.108.1.254/24 - is OFTEN used as the default gateway, the IP address of the router in NAT senses.

NAT: Network Address Translation

A technique developed to avoid address exhaustion in IPv4

We allocate our local network to be the IP address range 10.0.0.0/24, and each interface gets a local address.

Then the router is given a single address to represent the whole network (this is the address the rest of the internet sees), and we identify hosts with port numbers within the packets.

Specifically for a datagram:

Outgoing datagrams replace (source IP addr, #port number) [LAN side address] with (NAT IP addr, #new source port) [WAN side address] in the router.

Remember using NAT Translation Table the translation pairs we use.

Incoming datagrams use the table to replace the destination fields in IP & TCP headers.

😊

Only one IP address needed for multiple devices: reduces address exhaustion

Can mess with our local IP addresses without telling outside world

Can change external address and internal hosts don't need any change

More security as devices aren't explictly addressable: FIREWALL

😔

Violates end-to-end principle as needs to deal with layer 4 (TCP ports)

Address shortage could be solved in other ways (IPv6)

We may want a server behind a NAT.

difficult as no prior connections to source - outside machine, must know the right port number to direct to ?

😯 statically configure NAT to designate a certain machine to a specific port

😯 universal Plug n Play allows NATted hosts to learn public IP addresses and add/remove port mappings for external access.

😯 Relay system - client talks to relay, NATted server initiates comms with relay.

ICMP: Internet Control Message Protocol

Its messages are carried in IP datagrams: they don't transmite DATA, just set messages.

Structure:

Type - Code - Checksum

Combined in an IP packet with protocol value of 1

They are sent for error reporting and echo request/reply ALL over the place.

An example use is traceroute:

send a series of UDP messages with increasing TTL's (from 1) on an unlikely port number.

when the n^th^ datagram reaches the n^th^ router TTL expires, router discards the datagram and returns an ICMP message (with router name - found with reverse lookup + IP address)

When get an ICMP message back we can calculate RTT

😔

ICMP messages sometimes follow different paths to IP packets

Discover routes at the interface level not the router level.

Sometimes routes just ignore our messages cause they don't like ICMP.

Address Resolution Protocol: sending an IP address to the right place - linking network and data link layer:

Every node maintains an ARP Table of <IP address, MAC address> pairs.

When sending a packet we consult the table, if its in there then send it.

If the IP address isn't there, we broadcast "who has this IP address\*\*" and someone responds with their MAC address, then sender caches result in table.

😔 ARP allows people to impersonate IP addresses really easily, ARP poisoning is a classic security flaw.

Example: A Sending a Packet to B

Host A constructs an IP packet to send to B

Host A has a gateway router R: this is used to reach addresses outside its subnet.

Address for R learned via DHCP/config through broadcast

Host A learns the MAC address of R's interface

ARP request & response

Host A encapsulate the packet and sends to R

Router R's adaptor receives the packet

R extracts the IP packet from Ethernet frame and reads destination

Router R consults its forwarding table

Router R's learns the MAC address of host B

ARP request & response

Router R encapsulates the packet and sends to B

IPv6: solving the unnecessary complexity of IPv4 and address exhaustion

Protocol changes

Larger Address Space - addresses 128 bits long rather than 32

Increased MTU - networks can handle far more traffic than 1970s

No enroute/in-network fragmentation - simplfies handling of packets in network, hosts are expected to do Path MTU Discovery before sending.

No checksums in IP header but REQUIRED in UDP: this is inline with the end-to-end principle.

Extension headers - are used for extensions to IPv6, they are specified with the next header number which tells us the extension OR the protocol of the next layer.

Auto-configuration

Flow-label

Replace broadcasts with multicast

Addresses Details