Principles of Communications - week 8

This week sees us wrap up Traffic Management on all timescales, and thence on to Systems tool box of design rules, plus a couple of worked examples of specialised network protocol stacks, (see also data centres, discussed a couple of lectures back).

The last couple of problems to re-enforce  ideas, that you could look at by  end  of term next  week are 

1/ look at a day in the life of a video session - think about all the stages and different  protocols  and uses  that might be involved in getting a session setup, any  guarantees of performance, and the flow of packets  (and what happens if routing changed during a session, or one end or the other or even both are mobile users). what about multicast? what about multipath? and load balancing?

2/ design a peer-to-peer specialised file sharing network for users for in-flight entertainment. instead of a server and a bunch of thin clients in the seat backs in front of passengers, everyone brings their own device and content, and everyone can browse and retrieve or play content from anyone else's device(s).

If you'r interested in entrepreneurship, a business case would be that the airline gets to data mine/run analytics on passengers content preferences and can re-link it to their source/destination of travel and seat price paid, and sell that data to  content creators in lieu of payment for copyrighted content.

But what is the network topology? like a data center maybe (c.f. Clos switches)? or other? wired v. wireless? probably assume wire as people will want power at least.

Not in this course, but obviously security of such a system might be a consideration:-)

Principles of Communications - week 7

 This week, we looked at  how Data Center Networks  are a special case of the general internet, which permits certain simplifications of how things can be done  due to regular topology and more cooperative environment, so either known or controllable traffic matrix and source behaviours.

Optimisation is a lens through which to look at design. Network protocols - routing and congestion control - can be seen as online solutions to the joint network/user/traffic optimisation problem. Use resource as efficiently as possible to maximise power of net (e.g. minimise delay) and mazimise rates of users subject to fairness.

 

MPTCP  - optimisation never said anything that restricted us to single routes.

QUIC - we talked about equation based control derived for TCP - can we simplify protocols for lower latency and less head-of-line blocking for browser/server interaction in the web, and keep  compatibility with TCP - answer, QUIC...(work-in-progress).

Principles of Communications - Week 6

By Nov 13, we've got up Flow and Congestion Control, and Scheduling, and you can have had a look at problems up to P4 here.

I'll note that multicast circuit routing iis easy, because multicast IP routing is stateful (routers know where host members are) so the tree building algorithms that apply to IP multicast should work fine for circuits too,

The use of randomness in mobile is really mainly to prevent oscillation between base stations when a node is moving on a path between several choices - i.e. sticky random like the telephone trunk routing discussed.

Deriving Erlang is not too tricky - its just a random walk - see wikipedia for a good intro.

Deriviing Padheye's TCP throughput equation in full is a bit more complex - for those interested, see the original paper - the main thing is to draw the time sequence diagram of packets being sent, acks arriving, and the state variables, then, when there's a loss (indicated by duplicate acks or timeout), then the window halves or you trigger slow start. then just count the area under the curve. The one extra term in Padhye's equuation covers the case where the sender is rate limited by a "too small" advertised receive wiindow so they can't fill the "bandwidth*delay" product's worth of bottleneck capacity.

Flow control when end point is physical - fairly  straightforward to extend the feedback from an output device like a printer if it has monitoring of page rate (or jams) (or input device, like a scanner), through  the operating system, to the API to TCP (or similar) end-to-end protocol.

For consideration of batteries as a resource, no special reason to treat them differently than memory, CPU, except for human preference (risk of running battery flat before reaching next charging point might be a preference in the API for smart batteries/phones/cars) - see software defined batteries work at Microsoft (with Tesla)

Finally, this year we are not covering Control Theory itself due to lack of space/time in the course. However it is now covered in more detail in another Part II course (next term) - see Computer Systems Modeling.

Principles of Communications - week 5

 By Nov 6th, we've gotten up to the end of the routing material, having just covered mobile (internet and cellular, as examples of how not, and how to do it right) and then random trunk routing (in fixed line old telephone circuit based nets), which has re-emerged as am idea behind one way to do cheap and effective load balancing in packet networks.

Principles of communications week 4

  This week, we were covering BGP semantics and scaling, plus just covered Multicast routing.

For fun, this is a report on how a mobile operator misconfigured OSPF and broke their network - it is salient here because a centralised controller such as discussed in "Fibbing" could have checked the config and shown it was broken before applying....misconfiguration errors in BGP are also problematic and have even more potentially global bad consequences than just messing up your own AS. 

(OSPF=Open Shortest Path First, a very common link state protocol implementation used within quite a few ISPs - it also has some nice add on features such as Equal Cost Multipath, for load balancing).