Principles of Communications Week 4 to Oct 31st/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. One of the key objections to multicast is that, like broadcast, it has great power (reach) but also great potential for harm - as a tool for launching denial of service attacks on many people at once, it could be rather handy, for bad people....source specific multicast was one way to limit this risk (so that ISPs could police those sources) - indeed, it would be fun if one could only have source-specific unicast so one would only have to receive packets from designated senders!

Finally, multicast IP has the same packet lost characteristics as normal IP, so you need to put an end-to-end reliable protocol on top of it for applications like software distribution (though perhaps not for video/audio etc). - this isn't as simple as using TCP (or QUIC) as the acknowledgement mecahsnisms would not work well for large groups (each data packet to a group of N recipients would cause a flood of N acks which woiuld likely overwhealm the sender or the senders network access). So you need new multicast transport protocols that manage reliability differently. This is another challenge for using IP multicast - although in some limited deployments (e.g. data centers) it might be a good fit for some applications.

In the analog world (e.g. radio, or audio) broadcast is obviously both good and bad - spark gap generators jam all the radios within considerable range, and white noise generators mess with everyone's hearing nearby...

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.