# Connecting

#### Elasticity: Supply and Demand

This is about **resource management**

- **Supply** - Available link capacity on path
- **Demand** - Host transmitting and receiving traffic
- **Elastic** - capacity reduces -> demand is scaled back
  - Hosts stop sending / send less
- **Inelastic** - applications can’t handle this

TCP manages resource usage based on observed loss and latency

#### Quality of Service

If capacity > demand, there is no need for quality of service

If capacity < demand, we need to keep queuing minimal

- As queuing directly impacts latency, jitter and loss
  - In stable networks
  - **Jitter**: The difference in delays, a measure of stability

#### IP Type of Service

- Single IP header byte

```
Bits 0-2:  Precedence.
Bit    3:  0 = Normal Delay,       1 = Low Delay.
Bits   4:  0 = Normal Throughput,  1 = High Throughput.
Bits   5:  0 = Normal Reliability, 1 = High Reliability.
Bit  6-7:  Reserved for Future Use.
```

- Precedence for *special* traffic

```
0     1     2     3     4     5     6     7
+-----+-----+-----+-----+-----+-----+-----+-----+
|                 |     |     |     |     |     |
|   PRECEDENCE    |  D  |  T  |  R  |  0  |  0  |
|                 |     |     |     |     |     |
+-----+-----+-----+-----+-----+-----+-----+-----+

Precedence

111 - Network Control
110 - Internetwork Control
101 - CRITIC/ECP
100 - Flash Override
011 – Flash
010 – Immediate
001 – Priority
000 - Routine
```

### Differentiated Services (DiffServ)

- Operates on *traffic aggregates*
  - Label packets with desired class via ToS
  - Routers apply different queuing as operator sees fit
- Four service classes, or *per-hop behaviour*
  - **Default**: best effort
    - No QoL applied
  - **Expedited Forwarding**: low delay, loss & jitter
  - **Assured Forwarding**: low loss if within rate
  - **Class Selector**: use ToS precedence bits

##### Problems

- End to end semantics
- Mapping to service level agreement
  - If an internet company sells a network with a certain speed, this might have legal repercussions if QoS are enacted
- Mapping to application demands

### Integrated Services (IntServ)

- Operates on explicitly signalled *flows*
  - Think phone switchboards
  - The network signals exactly what it can and can’t do to the destination nodes
- Flow setup specifies some quality of service
- Routers perform **C**onnection **A**dmission **C**ontrol
  - CDA can accept and reject traffic based on whether or not the route/path is available

##### Problems

- Complexity
  - Hard to scale
- Mapping requirements to parameters
  - This was easier when ATM did it as they owned all the infrastructure
  - Whereas now it is difficult to map across all different companies
- Per-flow state
  - Extremely difficult

## NAT

### Address Shortages

**IPv4** supports 32 bit addresses

- 95% allocated already (440,000 netblocks)

**IPv6** supports 128 bit address

- Loads of addresses :white_check_mark:
- Routing protocols need to ported :negative_squared_cross_mark:
- Associated services needing to move :negative_squared_cross_mark:

### Network Address Translation

Because IPv6 did not magically solve address shortage problem and not all routers are ipv6 aware, we had to rely on NAT.

- Private Addressing, `RFC1918`
  - `172.16/12`, `192.168/16`, `10/8`
  - Devices with these local IPs should never be externally routed
  - Not for security reasons - just for getting more addresses
- Traditional NAT, `RFC3022` is the standard
  - Use private addresses internally (within the local network)
  - Map into a (small) set of routable addresses
  - Use source ports to distinguish connections
  - For large scale **carrier grade NAT** [`RFC6598`] on `100.64/10`

#### Implementation

- Requires IP, TCP/UDP header rewriting
  - Addresses, ports and checksums all need to be recalculated
- Behaviours
  - Network Address Translation
  - Network Address and Port Translation

###### Full Cone

![image-20220124180451508](/home/jay/.config/Typora/typora-user-images/image-20220124180451508.png)
```
ea:ep - NAT address : NAT port
```

When client receives packet from server 1 `da:dp`, the NAT translates the NAT address `ea:ep` to the clients internet address and port `ia:ip`.

###### Address Restricted Cone NAT

![image-20220124181009792](/home/jay/.config/Typora/typora-user-images/image-20220124181009792.png)
In this case server 2 is not trusted and therefore any request will be dropped.

###### Port Restricted Cone NAT

![image-20220124181127801](/home/jay/.config/Typora/typora-user-images/image-20220124181127801.png)

If the router receives a packet from a bad IP or bad port, it will be dropped.

###### Symmetric NAT

![image-20220124181325935](/home/jay/.config/Typora/typora-user-images/image-20220124181325935.png)

Here the internal address is obfuscated from the external servers, same client can use different ports for different communications.