158 lines
4.8 KiB
Markdown
158 lines
4.8 KiB
Markdown
# 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
|
||
|
||
|
||
```
|
||
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
|
||
|
||
|
||
In this case server 2 is not trusted and therefore any request will be dropped.
|
||
|
||
###### Port Restricted Cone NAT
|
||
|
||
|
||
|
||
If the router receives a packet from a bad IP or bad port, it will be dropped.
|
||
|
||
###### Symmetric NAT
|
||
|
||
|
||
|
||
Here the internal address is obfuscated from the external servers, same client can use different ports for different communications.
|