Principles of Communications - Final Week (to Dec 4)

Covered Systems and wrapped up with final problem class (see previous blog entry for comments on that).

Have now allowed access to the supervisor course web info, which contains this set of problems, and pointers to relevant past exam questions, whilst noting that the exams this year will be open book, so questions are more likely to be more about using methods, than just remembering the course material,

(A note on a couple questions:- quite a lot of network design hinges on economics- congestion control comes out of joint optimisation of user utility and network provider's revenue - in contrast to closed loop flow control, open loop also has an economic "pivot" point between user and network provider, but it happens at call or session setup time, where you are incentivised, as a user, to choose a low rate for your video (and a high burstiness factor, e.g. r&s in LBAP) simply because higher rates cost more.)

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).

Principles of Communications - Week 3

 By now, we're roughly up to BGP and traffiic engineering - see

Course Sequencing and associated problems

for the timing and also some suggested  problems to tackle as you're folloowing along. Also, I'm intending having a Q&A "drop in" zoom session on Tue Oct 27th, 11-12 - Zoom link is on moodle... 

Email me ahead of time if you have specific questions/things you've tackled you want feedback on! Asynchronous working is a far better way than lots of online meetings in  my experience...

Principles of Communications - Week 2

 This week we are up to centralised routing, both on paper, and in practice with ways to control MPLS or SR, for example - the Sequence, timing and problems for lectures are online too.

Principles of Communications - Week 1

You should have access to moodle/panopto + lab web pages with cached downloaded mp4s as well.

The intro to the course & to routing section is where we're roughly be up to now.

there's also an index for lecture order & data the material should be "covered' by, plus some suggested simple problems to look at, to test your understanding.

thanks (already) to folks who emailed corrections&bug reports on videos! appreciated - keep 'em comiing!

take care, and hope to see people eventually

cheers

jon