Principles of Communications Week 5 to Nov 3rd/L9

This week were covering Mobile Networking(*rant*) (briefly) and then telephony networks(^motives for innovation!) - architecture, but in particular, random routing as it is a neat illustration of the use of non-deterministic approaches to distributed systems which yields efficient results See also Valiant Load Balancing (for example this work at Microsoft, also used in Operating Systems (NGINX, for example. 

 For a general discussion of random choices and their application, see this study (very much deep background reading only!) 

 *rant* The TCP checksum is designed to protect end-to-end packets against corruption - it is fairly low cost to. compute (ones-compliment sum of all the 16 bit fields in the TCP header and application data) compared to more complex integrity checks used in lower level protocols (link level checks are usually designed to be implemented in hardware). 

However, it features one incredibly poor additional design choice, which is that the check also includes adding in fields from the "pseudo header" which includes parts of the IP header (source & destination addresses, protocol field and IP segment length). (see for details) This has two problems: firstly it messes with the fate sharing design of the Internet so that end system comms is now entangled with network layer. Secondly, it stops a TCP connection surviving IP address re-assignment, which is essentially what happens if you move network (e.g. switch from using your wifi to using your cellular data link). 

The argument made by the TCP designers was that this prevents some security threat from someone messing with your IP address. It is not clear that that threat actually really represents a real problem since nowadays, TCP implements multipath with multiple IP addresses and switches or combines them safely. Also other protocols (e.g. TLS, above TCP, or else QUIC, as a replacement for TCP+TLS) make use of a secure association between end systems, which is far more secure and resilient to mobility anyhow. So another mistake in the Internet design.

^Motivation for Innovation! The first automatic exchange was designed by an undertaker, Almon Strwoger who believed human operators were diverting business calls to his competitors - real story is a bit less interesting, but still important - precursor to the cross-bar switch!

Started on Flow Control - for closed loop/feedback control systems, this paper by James CLerk Maxwell, back in 1868 covered some nice maths behind how to desgin controllers!

Principles of Communications Week 4 to Oct 26th/L7

 This week, we'll finish up BGP, and cover multicast routing.

General lessons from BGP - information hiding can be harmful to decentralised algorithms. but information hiding may be a necessary dimension to some distributed systems due to business cases (commercial inconfidence/competitive data). 

Are there other ways to retain decentralised or federated operations but to retain also confidentiality? Perhaps using secure multiparty computations (not covered in this course!). There are a number of other federated services emerging in the world (applications like Mastodon and Matrix, and also, federated Machine Learning systems like flower) so this probably needs a good solution.

Multicast has a great future behind it - some neat thinking, but largely replaced by application layer content distribution networks (e.g. netflix, youtube, apple/microsoft software update distribution), and the move away from simultaneous mass consumption of video/audio. For more info on limitations of multicast, this paper is a good (quick) read.

Are application layer overlays a solution to other "in network" alleged enhancements? Possibly - for example, Cloudflare obviate the need tor always on IPv4 or IPv6 addresses - this also wasn't covered in this course, but might be of interest. Thir work is described here and other papers of theirs may be of current interest.

Tup A previously unavailable route is announced as avail- able. This represents a route repair.

Tdown A previously available route is withdrawn. This represents a route failure.

Tshort An active route with a long ASPath is implicitly re-

placed
with a new route p ossessing a shorter ASPath. This represents b oth a route repair and failover.

Tlong An active route with a short ASPath is implicitly replaced with a new route p ossessing a longer ASPath. This represents b oth a route failure and failover. 

Couple of questions on Graphs in last section on BGP 

1. A Few Bad Apples - graph doesn't asymptote, despite being cummulative as it prefixes can be announced more than once (i.e. > 100%!)

2 How long does BGP take to adapt to changes - the legend refers to

Tup A previously unavailable route is announced as available. This represents a route repair.

Tdown A previously available route is withdrawn. This represents a route failure.

Tshort An active route with a long ASPath is implicitly placed

with a new route p ossessing a shorter ASPath. This represents b oth a route repair and failover.

Tlong An active route with a short ASPath is implicitly replaced with a new route p ossessing a longer ASPath. This represents b oth a route failure and failover.

Tup A previously unavailable route is announced as avail- able. This represents a route repair.

Tdown A previously available route is withdrawn. This represents a route failure.

Tshort An active route with a long ASPath is implicitly re-

placed
with a new route p ossessing a shorter ASPath. This represents b oth a route repair and failover.

Tlong An active route with a short ASPath is implicitly replaced with a new route p ossessing a longer ASPath. This represents b oth a route failure and failover.

Principles of Communications Week 3 to Oct 19th/L5

Wrapping up with centralised routing, MPLS and Segment Routing - if you are interested in latter topic, see this survey of SR

This week, we'll start on BGP/Policy Routing, getting up to traffic engineering, including the amusingly named "hot and cold potato". Next week we will wrap up BGP covering semantics & performance.

A great overview of BGP if you want an alternate source.

Some General High level questions about material together with rough dates when each topic will appear in lectures.

Principles of Communications Week 2 13/10/2023

 This week we covered "centralised" routing - two aspects:

Fibbing - hybrid of SDN/central controller and distributed computation using link-state

(note on terminology. )

If you are interested in how to replicate state machines, have a look at this work on distributed consensus . Noting that these replication schemes themselves are very subtle and difficult to get right.

MPLS - and segment routing - which is somewhat stateful forwarding, which therefore requires some input from some controller or management plane to do anything other than default paths (if MPLS or SR just use the IGP to setup labels/segements, you just get whatever the IGP does, so kind of making the use of MLPS or SR rather pointless).

Some useful backup material on segmenet routing, operationally from Juniper Networks

Principles of Communications Week 1 5/10/2023

 

Today sees start of 2023/2024 year and for Part II taking Principles of Communications I'll be noting progress and also adding occasional related reading/ and corrections on this blog.

If you want to revise anything to warm up for the course, I suggest last year's Computer Networks course should be a quick re-read! A fun review of 40+ years of the Internet

This week we'll just make a start on routing.

For fun, you might find this discussion on why LLMs aren't much use for networking, mostly interesting - video recording of panel session

Reference requested for Glossary of Terms: from ISOC

Some acronyms come from the 7 layer model of the communications stack including terms like PHY (short for physical, so not really an acronym).