Thursday, June 11, 2026

tl;didn't red

Every year for the last 25 years, I've graded undergrad exam scripts in Cambridge. 

Every year, I reach for the same red ballpoint pen as the pile of scripts lands, wummppphh, on my desk. So this year, the ink pretty much ran out on that pen.

Is this a sign? Well, yes, it suggests biros are really quite well made, given how long they last, and whatever they use for ink has amazing longevity (as anyone knows who has had one leak in their white shirt pocket).

But it made me think - is there a lesson about the length and quality of an academic career that could be combined in this one metric: How long does that biro last?

The argument goes thus: the better you teach, the less red ink you have to use to give feedback (and grades) to students. so you are motivated to teach well (you can't game this by just setting easier questions, because there are second examiners and an exam board and all sorts of statistical checks across each student, each cohort, each paper etc etc). 

On arrival in cambridge, i suggest we give each university teaching officer a single red biro. and they get to retire (at least from teaching) when it runs out.

On a sample of one,  this roughly corresponds with my current expected retirement age (if you accept Cambridge's illegal EJRA arguments - but that's another story).

Fair?


(To note, I'm also attending an alumni dinner at Trinity College this year on the 50th anniversary of Matriculating (admission to Cambridge as a NatSci undergraduate). I also looked at my academic diary and note its 40 years since I formally started teaching (at UCL initially). I also recently met a 3rdyr PhD student whose advisor was advised by one of my past PhD students, so that's 4 generations of PhDs in one place - which kind of makes sense, if you think how long it takes from starting academic study to getting to the point you could advise others, then a generation is roughly a decade. so 4 decades of red ink.

Tuesday, December 02, 2025

Principles of Communications Last Week 8 2/12/2025

Today we wrap up this course with the network systems design toolbag of tricks. 

It could be instructive to take each trick and see where it showed up earlier in the course.

Statistical multiplexing - in conservation law and scheduling.

Pipelining- the entire idea both of a stack (vertical) and the network path (sequence of links and switches and routers) is illustrative of pipelining. Both closed loop and open loop flow control are trying to balance the pipeline, either through congestion control to share the bottleneck, or through admission control.

Caching/Locality - mentioned in passing memcached as a data center service, for example.

Batching also shows up in some data center distributed processing platforms (not really covered here)

Optimising the common case is probably something that BGP demonstrates how not to do!

Binding and Indirection - e.g. multicast addresses aren't real locations, but logical group identifiers, and the actual locations are distributed by the group membership protocol...

Randomness - as discussed in telephone routing! Also used in some load balancers when talking to replicated services (and flow or packet level balancing over multipath enabled routes).

There are many many other examples...

On the other, space could be cool but cooling in space could be very hard... this is maybe a nice example of how systems thinking can be applied using the simple laws of physics (gravity, EM radiation, thermodynamics) before you get as far even as thinking about resource management of processing, memory, comms.. ... ...

Things you do not need to remember:- Padhye's "simple" TCP throughput equation, and Erlang's call blocking probability ...












Tuesday, November 25, 2025

Principles of Communications Week 8 25-27/11/2025

tue: traffic management timescales, users, large and small, demands, short and long...

signaling and soft state


thu: systems design patterns


Monday, November 17, 2025

Principles of Communications Week 7 18-20/11/2025

 This week we'll cover


  • qjump[qj] - data center networking - a big special corner case of traffic scheduling.
note qj puts the token bucket pacer in a hypversions so it is a regulator and a policer in one. it could also be offloaded to a smart NIC If you had one, or just put in the guest OS if you trust it.
  • optimisation - routes for traffic, and traffic for routes
The start of traffic engineering by steering traffic by weights - note the hill descent is a classic old school AI technique.  And the origin of why tcp does AIMD is also a type of optimisation, of joint source and network utility!

Optimisation is a very large topic in itself,  and underpins many of the ideas in machine learning when it comes to training - ideas like stochastic gradient descent (SGD) are seen in how assign traffic flows to routes, here. In contrast, the decentralised, implicit optimisation that a collection of TCP or "TCP friendly" flows use is more akin to federated learning, which is another whole topic in itself.

Why a log function? maybe see bernouilli on risk

Why proportional fairness? from social choice theory!

Are people prepared to pay more for more bandwidth? One famous Index Experiment says yes.

0. See Computer Systems Modeling for why the delay grows quickly as load approaches capacity.

1. see IB Distributed Systems for clock synch

2. see prev year's Cloud Computing (II) module for a bit more about data centers&platforms.


[qj] The qj paper gives lots more details of setup, for anyone interested (the figures in the paper are clickable and take you to software and switch/network configurations and data).

Tuesday, November 11, 2025

Principles of Communications Week 6 11-13/11/2025

 We've revisited flow and congestion control - one way of visualising the progress of an adaptive flow&congestion control protocol is the time sequence diagram:-




but note this is a massive over-simplification as really what you see here is an ideal with only one source and (apparently) only one bottleneck queue. In reality, in FIFO queues, traffic from multiple sources mixes and interferences (causing high variance in delay, hence round trip time, and very unpredictable loss. If we had Round Robin (by flow) queues, things might be a bit better, but how much? That is what we look at under Scheduling, and with the Generalised Processor Sharing model, can see how close to some ideal of "isolation" between flows, we can get. 

With FIFO queues, RTTs and rates (as estiamted from data or ack packet inter-arrival times are going to be varying fairly chaotically, as the ensemble of flows at any bottleneck will not be coordinated in any special way as they all have different RTTs and perhaps just different performance senders, maybe different packet sizes, possibly different inter-packet timing at transmit time, etc etc


A combination of open loop (admission control) and closed loop (feedback) would allow sources to simply operate at a flat rate (the requested rate) or adapt above it as capacity is made free...

The trade off in flow control and scheduling is all about overall system complexity.



Next, we'll wrap up on queue management, then move on to the special (but important) case of data center networks and latency control!




Tuesday, November 04, 2025

Principles of Communications Week 5 4-6/11/2025

This week, we've got two random[ref] examples


1. random telephone routing

c.f. triangles

can we greedily find the tandem? (only) if you want to check the reasoning behind that part of DAR!

2. random drop congestion - serioiusly, today's lecture is mainly revision of IB congestion/flow control...

c.f.tcp arena 

how many TCPs are there, really? again, only here for the keen background reader!


ref: there's a very nice study of general applicability of random choices in this harvard paper if you want some more background reading...

separately, in a discussion with a supervisee/supervisor, i realise some people may be interested in looking at real code to reinforce their understanding - for IB material, I strongly recommend Rich Stevens' TCP/IP Illustrated Volumes 1 and 2, but for this course, there's not really any such a nice single text - an alternative might be this:-

There's a neat network simulator called NS3 which has real code in it - it is used both for routing experiments and for transport - the package also has a nice visualisation system, so when you configure a simulation with a topology of routers and hosts and links, you can record the traces of events (packets) and later 'play it back' with a nice layout - see
for where to get it & documentation including examples...

Simulations are interesting as they often (in this case) include fragments of real code from real systems, so they are also test harnesses. however, more fundamentally, packet-based event driven simulators are implented with much the same design pattern as packet switching systems (i.e. routers) - effectively the simulator is an aggregsation of all the event schedules for all the entities in the system confituation being simulators- there are basically two types of events
- timers - both for when to send periodic route updates/keepalives, and for tcp/quic retransmit type actions
- packets arriving to go to the next stage (whether next layer or next hop...)

Associated with events is some state (e.g. forwarding information base searched by destination address in IP header, or label switched path indexed by packet label in MPLS shim header) - or in transport protocols, the 
whole bunch of information about sequence numbers, windows and congestion, etc

Event driven code tends to look a bit different from classic application layer code
[that said, proxies/caches/servers can look similar).

From the router perspective, there's the event/timer driven distributed routing control protocol,

and separately theres the actual packet forwarding processes/threads ...the former (as i mentioned before) is often in the pattern of a unix daemon/service, whereas the latter is much lower level (and often has to interface to custom hardware for supportng fast lookup and even switch fabric interfaces) - there are open source routers other than just linux based (home broadband) ones - (e.g. www.nongnu.org/quagga ) but i think this might be a lot to read with few extra lessons..


Tuesday, October 28, 2025

Principles of Communications Week 4 28-30/10/2025

 This week we wrap up BGP - looking at abstractions of the algorithm (The Stable Paths Problem in Interdomain Routing) and concrete realisations of problems in implementations.

While you may find the stable paths model helpful in removing noise from BGP complexity, I am not so sure its a great abstraction for thinking about how actually to resolve the problem(s) (non convergence etc). A nicer approach (by same lead person, Tim Griffin) is meta routing, which is very powerful and general, but would need an entire other course to discuss and I just put here for background in case anyone is interested !


Then we'll next make a start on Multicast Routing. Two compelling applications were tv/radio broadcast and software distribution. However, application layer overlays (Content Distribution Networks) have subsumed those needs - a great example is how Zoom coordinates multiparty sessions - this talk by their CEO is instructive. Also interesting is this paper on netflix content distribution approach.