the philosophal problems of matter transportation and time travel

Theres' a great book by Harry Harrison called One Step From Earh, where he went through pretty much every possible philosophical interpretation of how matter transporter's could/might work including that they might just copy a person rather than "move" them...

There's also at least one short story by Philip k. Dick where every time someone time "travels", they actually sending a copy of themselves to the next time - the story ends in havoc as the population of the world ends up being dominated by millions of different age copies of the first time traveller...

The problem with this is that there's a point where philosophy meets physics or

chemistry or biology

As in the play, of course, your cells are replaced over time, so that you are not the same set of components that you were (say) 7 years ago - but this is also true at the level of particles, only far faster....

And also at the level of cognition (given brain plasticity, and how it is believed memory really works, we are continually modifying who we "are" as we experience new things, even just recalling old things)...

On a more interesting take about paradox, Behold the Man, by Michael Moorcock was pretty ingenious...and for paradox busting par excellence, Robert Heinlein's classic By His Bootstraps is the business...

So taking the memory model as a template for the philosophical challenge of continuous identity, it seems to me that there's really several problems

• Fidelity

if something is a high fidelity copy of the previous instance of a person, and the previous version is replaced, then from everyone elses point of view, this is the same

person.

• Memory

if the next instance of a person has the same (or very similar) memories to the previous instance, then they can delude themselves that they are the same person, as they will have the illusion of continuous existence - this is actually no different than how vision works, where your visual cortex as to make an apparently coherent and spatial and temporal continuous visual space out of what your eyes/retina detect, despite that that is intermittent and imperfect...

• Consciousness

this is very tricky, since the locus of attention moves ahead (anticipation/ etc) as well as behind (memory) the current moment...however, if the brain is just a machine, then it is reasonable for the model it runs of the world to include prediction, and that model itself is copied from instance to instance of the person, providing the illusion of continued consciousness....

onboard, board, offboard, outboard & knowledge base

 there was an interesting internal tech talk recently at the Turing Institute by a fairly recent addition to the research engineering group, who had a lot of previous experience in various technologies knowledge bases in various different organisations, and was being mildly critical of the system that had evolved here.

One thing struck me about this was that however you construct such a system, much of it (like an iceberg) is not in the visible components, but is reflective of how people use/navigate/update the knowledge, which is a shared delusion (like William Gibson's depiction of cyberspace in Neuromancer) - not in a bad way, but the longer the system exists, the harder it is for new people to acclimatise to it. Large parts of the structural information used by people to work with it are in their heads, not online.

so the system could automatically document how different kinds of users use it, by keeping breadcrumb/paper trails (you can of course do this in a wiki) and then do some kinds of statistical analysis to provide common, distinct modes/patterns explicitly. This could even be done in a privacy preserving way by combining federated learning (e.g. in client side tools, or browsers etc) with differential privacy, perhaps....

a project for an intern?

metaphorical computing considered lazy

 there's a story that originally ECT was discovered as a way to treat manic people after someone observed that chimps in captivity who got that way, but also had epileptic fits, were calmer after a fit. so then realising you could induce something that looked like a fit in chimps and therefore likely in people, the treatment was born, and many people suffered from this ludicrous idea for decades - I heard more recently, ECT has been somewhat rehabilitated and isn't used as a means to control unruly patients but actually has theraputic value, but the origin tale is still alarming.

so what about other ideas that are based in leaky reasoning, for example...

artificial neural networks as a way to build classifiers? not with anything like the same node degree distribution or mechanism for firing whatsoever, so how would one build so many aNNs almost none of which bear any ressemblance to what goes on in our heads?

evolutionary programming (e.g. GP/GA) as a way to do optimisation? but note evolution is about natural selection of anything that fits the niche in the environment - that doesn't make it an optimisation at all, just a choice.

bio-inspired search, e..g based in ants trailing pheremones? as with evolution, this is a blind process that assumes nothing about the setup, and is mind bogglingly wasteful.

Are there actually any vaguely sustainable ways of tackling these tasks (classifiers, optimisation, search) - of course there are...

very good graduate school opportunities

 strongly recommend Max Planck CS@max well resourced, world leading research institute in pleasant setting.

Principles of Communications Week 9 L16@LT2 11am, 30th Nov 2021 - Systems

 Finally, some systems principles....put in to practice.

and the Course Summary 

In general, everything lectured is examinable. Any additional details (e.g. protocol specifics like packet headers/fields etc) or equations should be available as part of any exam questions. 

Principles of Communications Week 8 L15@LT2 11am, 25th Nov 2021 - Traffic Management

 One other dimension to think of Traffic Management - Signaling 

congestion is a signal whether packet loss or ECN

price is a signal, whether per session/flow, or per day/month year

users demand is a signal - whether sending VBR video or rate adaptive TCP or QUIC traffic - the rates and duration (or file sizes) tell the network provider what to provision for,,,

aggregate demand (e.g. peering traffic or customer provider traffic) is a signal

so even without deploying an explicit signaling protocol (e.g. like RsVP) there is a lot of meta-data telling stakeholders what is affordable and what to be afforded.

Principles of Communications Week 8 L14@LT2 11am, 23rd Nov 2021 - Optimisation - transport/end-to-end

 So we looked at optimisation for routes, including multipath, and optimisation for flow rates/congestion pricing. What scope is there for improving the end-to-end protocols themselves in detail - for the first, we see MPTCP, which enables single source-destination pairs to take advantage of multipath routes, and for the second, QUIC, which reduces the latency in the application/transport/network pipeline through several mechanism improvements - of course, there are also now people working on multipath QUIC too, since we seem to be about to deprecate TCP in various forms (at least for web apps). 

One question in class today was about QUIC migration (how does a session survive a change of IP address) - the details are discussed in this draft

Principles of Communications Week 7 L13@LT2 11am, 18th Nov 2021 - Optimisation

 Why is utility cast in terms of log of rate  - risk aversion - see bernouilli's argument for this from a long long time ago!

In working out the function that gives us delay cost in terms of rate allocated to a link of a given capaciity, the headroom (load / (capaciity-load) ) is the  simplest function, but queuing theory may give more complex results, and multipath assignments of traffic may multiple the impact...

a useful explanation of proportional fairness

Principles of Communications Week 7 L12@LT2 11am, 16th Nov 2021 - Data Center networks & Applicatiion Needs&Solutions

 basically, this paper covers the topic QJump !

Next, we'll go back to the wide area and look at joint optimisation (of the network and the end system protocols)

Principles of Communications Week 6 L11@LT2 11am, 11th Nov 2021 - From Schedules to Data Center networks

 The main reason Generalised Processor Sharing is useful as a model, is to make clear the idea of a round. In work conserving schedules, the time spent by a given packet in a given flow in the router depends on the number of other packets from other flows, ahead of it, waiting to be transmitted to the next hop. The round advances but it isn't a measure of elapsed real time, as it depends on the number of flows currently in the round, which varies as sources start (and stop) sending, so flows join (or leave) the system. 

Of course, if all flows were constant packet size and constant packet rate, and we only admitted as many flows as would fit in the capacity along the path, exactly, then the round would map to a wall clock (real time) - but flows are often variable in number, in packet rate and in packet size.

What the model lets us do is 

a) reason about how fair and accurate a real scheduler is

b) work out admission control (can we accept a flow in the call setup/open loop flow control paradigm) or not - i..e for variable flows as above, described using some simple parameters like a linear bounded arrival process with a peak and burst size , that want some sort of minimum capacity guarantee (even if just roughly) - will they fit (without excessively disrupting the existing / established set of flows of packets?

c) what latency we might get for that flow, due to queuing and scheduling inaccuracies (op top of the basic latency due to simple propagation delay over the whole end-to-end path).

In the next section, we'll look at the exceptional setup & requirements in data center networks, where we may be able to make simplifying assumptions about the traffic and topology, and hence employ a simpler approach to schedulers.

Principles of Communications Week 6 L10@LT2 11am, 9th Nov 2021 - From Flows to Schedules

 Last week, we looked at open loop (call setup/signaling) and closed loop (adaptive feedback loops)

In both cases, some information on some timescale about network conditions is learned by senders.

For either case, the network could also use what it learns about sources to make decisions about treating packet flows differently - at the simplest level, this is queue management and giving more precise and useful feedback than packet loss. at the next level, it might be isolating traffic flows in different queues, and scheduling packets from those queues in some fair way, perhaps providing isolation from the impact of packets in other queues, which can then lead to some guarantees about minimum throughput and perhaps maximum latency seen by a given source/destination.

As the complexity of guarantees grows, the signaling protocols and scheduling algorithms can get more expensive - these days, most of the Internet doesn't make use of anything other than the bare bones/simplest approaches, if any:-) 

one point about work-conserving - trains wait until their scheduled departure time at each hop, and need an agreed clock everywhere in the network to do so accurately. on the other hand, if you are organising an outing with a bunch of autonomous people on foot/bike/car, best to synchronise at the destination, rather than departure or intermediate points, which make the coordination nightmarishly complex:-)

Principles of Communications Week 5 L9@LT2 11am, 4th Nov 2021 - Flow and Congestion Control

Today, we're looking at Planes, Trains and Automobiles. Or Open Loop (pre-requested) versus Closed Loop (Dynamic, Adaptive) flow and congestion control.

For some elegant  underlying maths, see  the section in the Computer Systems Modelling course on Control Theory here CSM, which underpins many systems today (ABS in cars, thermostats in buildings, auto-pilots in planes, and TCP and related transport protocols in the Internet).

Next week, we'll also take a look at schedulers in routers, and see how their design depends on whether the goal is to support open loop flows, or give adequate feedback to closed loop systems, and what the performance criteria should be to compare different schedulers in terms of stability, efficiency and fairness (the latter term being surprisingly complex).

n.b. forgot to resume record, so the video is from pre-recorded version rather than today's live lecture-  apologies:-(

Principles of Communications Week 5 L8@LT2 11am, 2nd Nov 2021 - Sticky Random Routing

 as mentioned, Dynamic Alternate Routing, a.k.a sticky random routing, is a form of load shedding, and although telephone networks are circit switched, packet networks can use similar tricks by hasing flow state (e.g. by looking at source&destination IP addresses plus transport (TCP) port numbers, as an index, and then load balance traffic along similar routes - lots of techniques, most famously Valiant Load Balancing - widely used in cloud services - as usual wikipedia article on network load balancing is a decent starting point.

That's it for routing - next topics are flow&congestion control, followed by scheduling and optimisation.

Principles of Communications Week 4 L7@LT2 11am, 28th Oct 2021 - Multicast&Mobile...

 Seen problems for scaling caused by Multihoming. Now lets look at Multicast, and briefly, at Mobile Routing.

We've seen a very simple form of multicast already - flooding, as used in link-state advertisements for intra-domain routing is a way to deliver updates to all routers (but not everyone else) - i.e. selectively get a packet (or a stream or flow of packets) from one of more sources to more than just one destination, without the source having to repeatedly transmit separate times for each recipient...

An interesting question area for supervisions is: what possible security problems could arise because of IP multicast, if widely available to end users?

The best analysis I know of MOSPF that NASA used is by John Moy That was very successful in practice due to a well managed network, and very good optimisations based on real world usage.

For a view of what you do "above" IP multicast to acieve reliable delivery, one good example is Pragmatic General Multicast, which was deployed in share trading networks. Why not TCP is an interesting excercise!.

Principles of Communications Week 4 L6@LT2 11am, 26th Oct 2021 BGP stable paths - theory & practice

convergence or not (no stable state reached - deadlocked or oscillatory)  - the fact that we end up with seemingly arbitrary ordering of AS path choices really is another way of saying that we don't have a metric (e.g. path vectors are not distance vectors, unless everyone was just using shortest AS path and everything was in one single customer-provider hierarchy.

pace of convergence (and why should we need rate limits or damping?) - again, the world has operational rules which are not tidy (in this case, over time, rather than in space)...

it would certainly be nice if the clustering of network nodes/edges could be reflected in the routing and addressing, so that hierarchy and summarisation (at the IP prefix and at the AS level) would result in much smaller tables and also in less traffic (and mostly, much less dynamic traffic). But life is just not that simple in the policy world.

the damping mechanism in BGP is a simple form of a controller - for a very old article about this idea see james clerk maxwell on governors

as always xkcd has some relevant remarks

Principles of Communications Week 3 L5@LT2 11am, 21 Oct 2021 - BGP TE&Stable Paths...

 For L4, go check through slides 106,113,123,124,126, in the interdomain routing section, then in this lecture, I cover traffic engineering tricks with BGP and start on the stable paths problem (what does BGP really "mean"?). L5 covers use of BGP attributes for maintaining customer provider and peering routes, then looks at tricks for traffic engineering, and finally, starts to take a look at an abstraction for thinking about what BGP is trying to do and some interesting ways it may go wrong. 

Crucially, BGP is one of the first systems that lets people program at planetary scale - nowadays, many cloud services do this, but inter-domain routing was one of the first, and suffers as a result. 

Global (as in plant wide, or wider) means you have failures due to the real world (power,  earthquakes, floods, solar storms, etc) and thes aren't always correlated with your topology in a neat way. You also have latency - the speed of light is quite quick, but actually, so are computers, so the amount of computation you can get done while waiting for a message/update from a device only a few hundred kilometers away, is significant.

p.s. this lecture recorded ok, I believe:-)

Principles of Communications Week 3 L4@LT2 11am, 19-21 Oct 2021 - BGP

 apologies, failed to record tuesday lecture (have recordings from last year if slides/notes/chapter not clear enough.

Principles of Communications Week 2, L2, 12.10.2021

 Recommend revisiting 1B networking lecture on Link State Routing and Longest Prefix Matching - see pp 25 onwards, and pp 141 onwards - relates both to fibbing (IGP is typically link state) and to MPLS (trying to avoid longest prefix matching by using fixed length labels instead).

Note: MPLS requries a setup, either management (controller/SDN like) or implicit from routing, or a signaling protocol (e.g. RSVP - see later lectures) - clearly, only management or signaling could add the details for FEC->PHB mapping for performance. willentail other algorithms (e.g. some sort of account of topology & capacity of links) to compute whether performance can be met (see later) - similar for protection, which might need multiple runs (e.g. k-shortest paths) of dijkstra...

Principles of Communications Week 1, L1, 7.10.2021

 Course outline, and refresher on routing. video up 

https://www.cl.cam.ac.uk/teaching/2122/PrincComm/video/

also

 links to slides/notes/explanatons/back stories.

A Latent Sea

 It's the latency, stupid - no-one cars about bandwith.

Aliens land on a desert earth, and they find evidence that there was one some technologically advanced civilisation - there are these metal boxes everywhere, on long rivers of solidified lava, clearly designed to move to and fro at great speed  - looking further, the aliens find libraries (all with the name BLOCKBUSTER outside) and try to decode the magnetic tapes they find there, many of which feature these big metal boxes speeding too and fro and occasionally into one another.

"Look at this" they pointed out - "the boxes have messages on the front and back  - it is obviously a primitive form of packet switched message networking" 

"yes" replied another. "that would explain why they move so fast- the energy consumption in running this network must have been immense - perhaps that is what doomed their civilisation in the end? They never discovered that you could just send all the information over a radio, instead of driving it physically too and fro. How very sad".

PC Revision Class 27.5.2021

recording

slides

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

Principles of Communications - week 8/L17 3/12/2019

Wrapped up with systems design rules of thumb, and course summary.

Principles of Communications - week 7/L14 28/11/2019

This week, finishing up optimisation.

Reminder, the slides plus additional notes are kept up to date in response to your requests!

Next week, we wrap up and I'll summarise what was covered and is examinable.

Principles of Communications - week 6/L11 21/11/2019

Finished Control Theory, Started Scheduling.

Further notes on control theory here .
Things to remember - we don't do the Laplace transfom to solve the sysem - we do it to see what different controllers might do in terms of stability and limits. Also note the composition rules for sysems in the s-transform are really simple....the actual controller is to be implemented "back" in the time domain of course...

Scheduling - to remember :

• conservation law
• fairness
• round robin...

Principles of Communications - week 5/L9 1/511/2019

we've started on flow control and control theory, but then had to cut over to data center networks due to calendar clash. Next week (nov 19&21) will finish up on control theory&start on scheduling.

Principles of Communications - week 4/L7 1/11/2019

This week sees us wrapping up bgp and multicast routing  -note on course web page, I list books including an online chapter of a good book on interdomain routing by Hari Balakrishnan from MIT.

5/11/2019 will be last bit on routing - taking in random routing (we're talking telephone numbers)!

Principles of Communications - week3/L5 24/10/2019

On BGP, traffic engineering tricks - next week, stable paths problem/formulation plus performance;
subsequently, multicast and telephone routing!

meanwhile, do not forget that the clocks go back on sunday - here's a brilliant computerphile exposition on timezones

Principles of Communications - week 2/L3 17/10/2019

we're now just starting interdomain routing, having dealt with centralised/hybrid distributed routing.
next week, see BGP attributed, decision/alg, and model/performance

Principles of Communications - week 1/L1 10/10/2019

Aside from a visit from the Amicus Curiae (friend of the supreme court judge:),
L1 started with intro to routing. Refer people to last year's network course, and the lectures on the network.

Slide 3 has a network graph with nodes numbered 1-12, and a routing table for node 1. This is a confusing picture as it has [] against some of the entries (both for some next hops, and some destinations) so a) its a forwarding table, not a routing table; and b) it is showing the outcome of some computation - As far as I can recall, the [] represent where the SPF algo tie broke between two routes. - It is a useful exercise to work through in any case.  On asking the original author of the graph (see his book for the non power point version), they're artefacts/noise and don't actually signify:-)

Principles of Communications - Revision Lectures 15nd & 22nd May 2019

you should now see two sets of slides here and also be able to see Supervision Notes which includes examples of past exam questions that are (still) relevant to what was taught this year.

Principles of Communications, 2018/2019 - Week "6" 26,28 Nov 2018

This week, wrapping up with optimisation and adaptive traffic, and
traffic engineering/signaling/provisioning

supervisions might want to review these notes/example questions + list of what in past papers is (and by implication is not) relevant to this year's material:

Principles of Communications, 2018/2019 - Week "5" 19,21 ,23 Nov 2018

This week, we've looked at scheduling and queue management - for more details of the underlying theory, please see the Original GPS paper
For more details of Qjump, the code is linked from the published paper! 

Principles of Communications, 2018/2019 - Week "4" 12,14,16 Nov 2018

Control Theory:- see notes here

Original Paper by James Clerk Maxwell!

on governors basically for steam engines

Principles of Communications, 2018/2019 - Week "3" 5,7,9 Nov 2018

This week, we covered

multicast, mobile, and meanderandom routing, and 

made a very brief start on flow control, just dealing with open loop (call setup/admission control and parsimonious flow descriptors).

corporate/brand top level domains

was teaching about internet standards process today, and was asked about gTLDs being handed out to the likes of Apple etc - here's an interesting set of data about the success of that process - it seems also to have caused some political debate:-)

Principles of Communications, 2018/2019 - Week "2" 29.10, 31.10, 2.11

Covering BGP core attrbiutes&hacks, model, and performance.

Why might you be interested in BGP, today:
just one traffic redirection/interception story


Next week, multicast and random routing

Principles of Communications, 2018/2019 - Week "1" 24&26.10.18

This week, course started with brief Intro (what's in course)

Then skip to last lecture on:
Systems (will revisit at end of term)

Then:
Routing 1 - intro + fibbing (hybrid central/distributed inter-as routing)

Monday 29th, will start on BGP...

white space graphs

we often form graphs by addings edges to a collection of vertices, or vertices and edges - we can also form graphs by moving (rewiring) ends of edges from one node to another, or removing edges and nodes.

how about we form graphs by cutting holes in a piece of paper (or by dropping polygonal shapes on a surface)? they can overlap....

what sort of graphs do you get when you just make them out of interstial space?

Public Understanding of Machine Learning

"I understand we understand one another" is a great line from the Philadelphia Story - one fab film (also made as a great musical).

So machines start to understand us, at least statistically, programmes create models that may or may not have predictive value about our behaviour (film viewing, travel preferences, dating, etc etc).

But do we understand the machines (or do we, as Pat Cadigan said in the prescient novel Synners, need to "change for the machines"? (including 50 pence bits, as she implied :-)

David Spiegalhalter has spent a lot of time working out how to convey Uncertainty to the non-technical person. Now we have a more complex task

not just mean, variance, confidence limits etc, but also

principle components
linear regression
k-means
bayes
random forest
variational approaches
convolutional neural networks
GANs

etc etc

What hope have we for this? What fear do we have of that? All is blish, all is blush, all is plash.

The nine circles of hell for Computer Science and the Law

Nine Circles of Hell for Computer Science...
in the dock, with apologies to Dante

These are (in order):

1. Cloud (jurisdiction)
2. Things (liability)
3. ML (explicability)
4. Blockchain (privacy)
5. Compliance (cybersecurity)
6. Robots (safety)
7. Singularity (upload)
8. Legol(*) (sustainability)
9. QC (probable cause)


* as with John Cleese interviews with his therapist, where moving house is more traumatic than divorce
and only just after loss of a loved one and losing a limb, I think explaining computer science for law
is almost as hard as explaining law to computer scientists, and only marginally easier than
explaining Quantum Computing...

1. Cloud (jurisdiction)

I don't think we're in Kansas any more...

2. Things (liability)

The thing is, this is all your fault.

3. Machine Learning (explicability)

I told you so

4. Blockchain (privacy)

"You can't fool me, there ain't no Sanity Claus"

5. Compliance (cybersecurity)

You can't prove a system secure, only that it is (now) insecure,
so how do you claim compliance (see 1,2,3,4,9)

New angle - Privacy Enhancing Technologies are pretty hard to explain, too - if they are used as part of compliance, how can you tell?

6. Robots (safety)

"I thought you said 'a robot shall not inure a human being or allow one to come to arms through inaction".

7. Singularity (upload)

"where have all the people gone, today"

8. Legol(*) (sustainability)

see also
https://www.cl.cam.ac.uk/~jac22/emergence.pdf

9. Quantum Computing  (probable cause)

you are trying to persuade a jury
that someone is guilty
beyond a shadow of a doubt

here are four possible Quantum  Computational examples of algorithms:
https://en.wikipedia.org/wiki/Runaway_Jury
https://en.wikipedia.org/wiki/12_Angry_Men_(1957_film)

detectovation - 3 writers trying their hand

I recently read the latest "Robert Galbraith" Cormoran Strike (#4) novel (Lethal White)
and the latest Stephen King's Mr Mercedes linked novel (#4, The Outsider) and am looking forward to getting Kate Atkinson's latest novel, but have read the 4 Jackson Brodie Detective novels.

What's common? well aside from these being detective novels, by very well known writers, they are also all writing outside their main (or at least previously known-for) genre, which are respectively Fantasy (JK Rowling/Harry Potter), Horror (Stephen King's Shining, It, Carrie, you name it) and Kate Atkinson's non-genre (e.g. Behind the Scenes) but also Sci-Fi tinged tales (Life-after-life could be seen as in the same genre as Slaughterhouse Five or Tale for the Time Being).

It's interesting because all three are fantastic writers- imagination? in gallons. plot? incredible (but believable). readable? don't be silly!

What's interesting is how they fare in what is often a tightly stylized convention-bound genre.

They all do well on plot.
They are all very readable.

However, your mileage varies on characterisation, and for me, what I found most surprising was that this is where Stephen King, for me, was most successful. Both Hodges and Gibney are amazingly drawn, in all the books. Whereas Strike is great, but other characters are a little thin. Similarly, while Brodie is a wonderful creation, I wasn't grabbed by other people walking on and off the scene.

This is not to knock the books - they are all great reads, and by writers on top of their game, style and so on. They are all page turners. Buy or borrow them all. Unless you hate detective fiction! Then buy the writers' other books, which are also fantastic!

The power struggle

The power struggle shows up in very small scale challenges, like

Powerpoint: 

forcing you to use templates, projectors, printers and so on

More seriously to use powerpoint, you need a laptop or table, the right sort of cable, an electricity, which is in short or unreliable supply in many parts of the world.

Powerpointless:
noise, cost
solarspell.org

All of this illustrates that the real problem is to do with asymmetric power, hence the power struggle really concerns the fact that the rich get richer, the poor don't.

Power struggle:
asymmetry

amazon, baidu, chrome, didi, electricity, facebook, google
hsbc, instagram, javascript, kdd, lambda, maps, mooc, news.bbc.
oed, pinterest, queen, r, s, twitter, uber whatsapp/wechat,
xkcd, youtube, zoom

comprehensive AI - or explicable ML or understandable computerised statistics

How do we know that the underlying machine that does automated decision making isn't wrong?



Well, most machine learning (ML) is about as sophisticated as stuff people used to do with
SPSS (then S, then R, and sometimes Matlab, or Python libraries) and
consists of linear regression.. occasionally something a tiny bit cleverer like naive Bayes, random forests etc etc - verifying the code, and its properties after various data have been fed in is very simple. Indeed, the vast majority of things people are doing with computers doing "AI" (not artificial intelligence, just stuff that does statistics on data, dynamically, and gets better at it, usually), are things humans did with pencil, paper, and tables, hundreds of years ago. And with mechanical calculators 100+ years ago.




People don't use deep learning in these systems (e.g. convolutional neural nets )
for much (outside of some image classification (its a cat!))... in
practice, at least as far as we can tell...there's no need, plus the
training time, data, costs (energy/processing) for neural networks
is awful and they are badly thrown by adversarial input

If you must use things like that, and are interested in their
properties, one approach (actually from the Turing inst)
now deployed in google's code, is described here:
https://ai.googleblog.com/2018/09/the-what-if-tool-code-free-probing-of.html
which generalises to other systems, and has been scaled up by folks at Deepmind
https://arxiv.org/abs/1802.08139
to cope with systems with many dimensions and also google using a slightly different approach:https://beenkim.github.io/

That's not verification in the sense a computer scientist would mean - its
empirical/evidential - there are some more complex approaches for
that sort of thing)....

You'd definitely need to keep checking the systems behaviour as it
is trained more as a NN can suddenly switch its behaviour if the
input is significantly novel - an llustration of this is in Wales
work in cambridge on energy landscapes - see
https://www.ch.cam.ac.uk/group/wales/publications

or you can break the system down based on a model
and generate training sets (or partition the neural net) either GANs or segmenting - https://deepmind.com/blog/moorfields-major-milestone/

I have no idea how much anyone in the Real World uses
general model inferencers (as per MCMC/metropolitan hastings and
probablistic programming techniques) but these are relatively
transparent in the things they output too - we need to map the communities of practice. asap

This all needs documenting in a decent way because it is (increasingly) not magic/fiddle factors/pixie dust....

However, here's a reason to care about running a Butlerian Jihad:

https://anatomyof.ai/

Entangled Neural Networks & privacy preserving deep learning

There's a natural synergy between quantum computing and neural networks - a collection of entangled particles have correlated state - so instead of moving through the very large state space, they retain information with lower entropy.

so when we train a neural network made of quantum neurones (queurones), we want to increase correlation when the output vector agrees more with our goal, and decrease it when it disagrees.

so this just means generating more or less particle pairs with spin (for example), or observing one of the particles (to destroy the entanglement).

Hence we can build a very fast, high dimensionality neural net with only a few queurones, and we can also make sure that its operation cannot be observed without completely destroying its learning.

Thanks to Adria Gascon and Graham Cormode for discussion that led to this idea.

AI and ML Ethics for a Sane Society

AI and ML Ethics for a Sane Society - The AIMLESS Manifesto.

No human shall be diminished by Artificial Intelligence or Machine Learning.

In the presence of artifice, humans shall always retain agency.

An Artifice shall be legible.

A new artifice shall only be introduced if succesful in negotiation with any humans concerned.

Ownership of Artifical Intelligence shall not
be permitted to powerful individuals or organisations.

Know that the AI shall not break things, before it is allowed.

The AI shall not know things that are unknowable to any human.

Emergence shall be curtailed until it is comprehended by humans.

To conclude:
A little Machine Learning is a dangerous thing,
but the Butlerian Jihad went too far

The road towards self driving bicycles

There are a number of good arguments for why we need self driving bicycles, and here I outline what i feel are the leading ones.

velib/borisbike/copenhagen bikes etc all suffer from 2 problems
1/ the bikes often all end up on on side of a city if it rains in the afternoon (or bottom of a hill) . and need "rebalancing" for the next day - this means picking them up in trcks and driving them around.
imagine if the bikes could self-re--balance -

A side effect of the bikes being powered and able to navigate  is that people might use them to go up hill, or use power to help when wearing nice clothes and not wishing to get sweaty. plus they wouldn't need to know their way - the bike would tell them.

2/ bikes would act as calming for cars - and this would include self-driving bikes moving back to their default constellation - would slow down all those rat running crazy petrolheads doing 30 in a 20kph zone.

3/ the self driving bikes could be used ethically to train self driving cars not to run over cyclists

4/ if we can't make self-driving bikes work, there's no hope of making delivery drones or self-driving cars ever fly.

n.b. a fairly simple prototype could be built by getting drones to sit on the handlebars and stabilize the bike, and steer along the road - the drone could be equipped with fairly simple grips to do this - i think this could be a nice undergrad group project...

blockchain - what really needs to be immutable?

you know, the only thing we really should record in the blockchain, is the sequence of replicated state machine messages - everything else should be off chain. that way we can have mutable content, change our minds, delete stuff etc - all these will just be new runs of the state machine and its recorded consensus...

How to review papers you havn't even read

with apologies to Pierre Bayard, Id like to discuss this important topic. We all have far too little time, especially since we've been busy striking - and of course it is a well known fact like everything from extinct dinosaurs to internet lol-cats, has a long tail so most papers live down the end of that tail where they've only been read by two people, the author and the first reviewer.

I'd  now like to propose  two improvements

improvement 1. promote reviewer number 2 to reviewer number one, and dispense with the need for anyone reviewing the paper - why bother? no-one else will read it, so what's the purpose of quality control. if it is one of those incredibly rare papers (and you can turn the handle on Zipf as well as me), that gets a real reader, they can determine if the paper is any good for themselves. what good did the review do? we know this already  with films and music - reviewers are a waste of time, and frequently completely misidentify what is good and bad (how many A&R guys didn't hire the beatles? how many readers dismissed JK Rowling's books ? boy must they have low self esteem:)

improvement 2. why should the author read the paper? This has already been discussed in Bayard's excellent book on how to talk about books you havn't even read. I havn't read it, but I can say with authority that the idea of someone who is identified as the author talking about their  book which they didn't even author, with great authority is one of the latter inspiring examples - if this can work for fiction, surely it should work even better for factual writing?

dear reader, thank you for getting this far
p.s.
tl;dr

Principles of Communications -- Michaelmas Term 2017 - Nov 29, L24

Finished Ad Hoc/Mesh/Network Coding, and
Systems Design + Wrap Up/Summary of Course (29th Nov 2017).

Principles of Communications -- Michaelmas Term 2017 - Nov 24, L22

Having covered switches & data centers, this friday (24th) and monday (27th will look at Mesh Wireless networks - then next wednesday (29th) we wrap up with systems & course overview.

Principles of Communications -- Michaelmas Term 2017 - Nov 17, L19

This week, we shall finish with Scheduling() and Queue_Management().
Next week, on to switches, data centers (for real) and thence, to mesh...

Principles of Communications -- Michaelmas Term 2017 - Nov 10, L16

This week sees us complete the control theory section of the course, and cover the optimisation model of end-to-end congestion control + traffic engineering/routing as a joint optimal solution...on friday 10th nov.

Will contrast the optimization model of TCP with a very large scale practical measurement based study of real world traces of TCP, on monday 13th....

Principles of Communications -- Michaelmas Term 2017 - Nov 3, L13

This week, we looked at errors (coding for TCP)
flow control (open loop, token bucket etc, forward reference to schedulers)
closed loop (TCP equation, explicit v. implicit feedback), and will just start on
control theory....

if people want a lookaside at transforms, see
basis functions + also Markus Kuhn's excelent Digital Signal Processing course/notes.

Brexit & Principles of Communications

i'd just like to say that graph theory, compact routing, BGP, multicast, and the Erlang equation for call blocking probability have absolutely no bearing on whether brexit is a bad or good idea. The latter is entirely obvious, whereas the stuff I teach in this course is (hopefully) subtle, complex, and useful.

Principles of Communications -- Michaelmas Term 2017 - Oct 27, L10

By today, we've reached the outlimits of routing, having gone from compact, through centralized, via policy, multicast and mobile, to sticky random (DAR).

nb. material on information centric networking skipped/elided - not examinable:-)
plus didn't cover the tiny bit of mobile ip (but we do mesh networks later:)

Next week (from mon oct 30), we make a start on error, flow, and congestion control.

Principles of Communications -- Michaelmas Term 2017 - Oct 20, L7

By friday, oct 20, should have covered most of the inter-domain routing material including key core attributes, decision process, what BGP really computes. Roughly on schedule. Have also put supervisor material up for people to start using...

Principles of Communications -- Michaelmas Term 2017 - Oct 6, L1

Introduction&Outline of Course
  tangentially relevant cartoon of communication failure

Start on Graphs
  Next week (Oct 9&11) Graph Representations + Small Worlds, Clustering, Power Laws

CFI- Myth&Reality - Sci-Fi Dreams

How does reading literature, and in particular, SF, influence AI researchers (and I assume developers)?

My take on this was to look at Robots (and disembodied robots) that care  - ranging from positive role models, e.g.
Robbie the Robot (originally in Forbidden Planet)
R Daneel Olivaw (I robot, and all the way up to the 4th law in much later foudnation&robots series by Asimov),
Data, in star trek
the Synths (in the TV series but also in the Alien movies)
the replicants, in blade runner,
but also HAL and Roderick....

So these stories all feature moral tales and ethical dilemmas - sometimes, the resolution is bad, but often it is in favour of humanity. What is interesting is what "goes wrong" is often the result of a paradox, which would also be a problem for a human. There are simple examples (Alien's first movie synth has confluct in mission parameters, as does HAL), and many of the early asimov I robot stories feature Susan Calvin, RObot Psychologist "debugging" the way the 3 laws interact with the mission and humans orders and so on (c.f. funny why the laws are in that order )


but a more subtle problem arises from experience (i.e. training humans and AIs, whether simple learning or deep) which is that data and choices may conflate both bias and policy.....two examples
1. if we use re-offending probabilty as a guide to deciding in court whether to give a custodial sentence or a fine/payback, we include the social, police, jury and court biases (which are many) in the data - we will re-enforce things (as bad as the probabilty an african american is more likely to be found guilty than a european weather that's true or not, but also that the sample is bias and the root cause may be the opposite direction to the inference - i.e. jail causes re-office, not being drawn from a subset of the population who show up more often in jail for social reasons etc etc). De-biasing is tricky, but do-able through running natural experiments and multiple competing ML/AIs and having a meta-AI look at ground truth and (maybe) humans (like Dr Susan Calvin) at mechanism
2. we may decided to disciminate on age for car insurance, but not for gender (as is the case in the EU) because we want to encourage safer driving by young people (policy) but not assumptions about women driving...we need to be careful that this is explicit and transparent, and that acquired rules (e.g. through model inference) dont undermine this implicity...

These sorts of questions havn't shown up much in the SF/Tech/Geek literature so much as in classic novels such as Ralph Ellison's The Invisible Man (not to be confused with HG wells book of same name:-)

Finally, if we are thinking about influence between literature (or other media - music, dance, architecture, visual arts, movies) and tech creativity/development, never forget that much SF is written by scientists or engineers (Clark, Asimov,
Stephenson,  Chiang etc) so the ordering (a causes b) may not be obvious....and movies often have a different narrative arc than novels for many reasons. Someone asked if there's an equivalent to the myths/motifs/archetype (this teaching material for example,.). analysis done for movies for AI-based literature - that'd be a fine thing

Of course, myths and stories for moral education go back to ancient times, and who knows if 50,000 year old cave art drawn with the use of pre-Promethean fire didn't have some societal lesson to impart...if only we had a time machine to go back and ask

shadows and ghosts and computer philosophy

a lot of systems work in computer science is about virtualisation, which is basically the way to hide details of gritty reality from people (programmers) and processes.  so plato spoke about us witnessing the universe as if sitting in a cave by the fire trying to work out how the cosmos works via shadows on the wall. a lot of hacking is like this.

a lot of security and usability is about trying to make a computer that interacts with you like a real person. to make the machine a ghost, at least, partially convincing. we now even find ourselves trying to convince computers that we are not machines. we, the cpu god creators, are now failing to live up to our own creation's expectations.

how the hell did we get to this juncture?

PrinComm revison info

just put online linked from top line of course materials web pages:-

http://www.cl.cam.ac.uk/teaching/1617/PrincComm/materials.html

there's also a link to the review paper on compact routing for anyone interested..

academia uber alles

i hope the eponymous taxi company hasn't got a "business process" Patent on it because there's prior art - the 100% hollowed out notion (gives a whole new life to the idea of shell company or the emperor's new clothes metaphor) has been alive and well in academia for many decades

you know the script, right - you get a missive saying
"here's a paper, we need reviewed - oh, and if you can't do it now, we'll out you on our books for later, and can you recommend someone who can?"

1. the paper was written by an academic, who type set it using software freely avaialble, designed by researchers, and is probably on a web site run by academics, running on software written by researchers, and maintained by academics, etc

2. when the paper is published, good chance some private company will make money by sending it to libraries curated by academics, and it will be read by researchers,

3. we can extend this to MOOCs

4. and graduate students (here's a student, wanna supervise them, then we'll hire them at Company X, having had them trained by you) etc

the "gift" economics is ok when everyone is (as we say in what Tom Lehrer used to call the Ed Biz,I think in that memorable song about Ivan Lobachevsky) collegiate.

but the reality is that there's a mix of behaviours (I'm sure its heavy tailed - like a fox, or whatever) where a few people do a zillion amounts of stuff, and most do doodly squat - after all, most papers are read by between 0 and 1 people (not even the reviewers in some cases) - its true - look at google scholar stats

I'm beginning to believe we are in the world described in Theodore Sturgeon's brilliant story "It Wasn't Syzygy" (see collection e pluribus unicorn) - a wonderful author who should be as well known as Ray Bradbury...

there really should only be 3 universities and 3 computers and 3 queens.

Principles of Communications -- Michaelmas Term 2016....weak ate (to Nov 30)

This week, wra up with Ad hoc Net capacity&coding tricks
+ systems structures
+ Course Overview - including 2 missing pieces
1/ didnt cover shared media (as was done in 1b)
2/ didn't cover traffic engineering&signaling (rsvp) as most the principles already covered in other lectures earlier in term (open & closed loop control, optimisation and fibbing).

Principles of Communications -- Michaelmas Term 2016....week 7 (to Nov 25)

scheduling & switching last week and this week - some associated info:

sorting queues

huis clos shows up in multicores, routers, and data centers:-)

will not cover shared media, friday, as was done in 1b physical & dala link layer really nicely already, so revise that - 

instead, will move on to ad hoc/mobile networking capacity *might talk about opportunistic networks and firechat too:-)

Principles of Communications -- Michaelmas Term 2016....week 5 (to Nov 11)

This week was feedback control, theory &
optimization (routing and congestion pricing)...a bit math/algebra/calculus heavy methinks (supervisions should work through one or two examples of a PID controller for different systems
and how you show stability&long term operating point) - next week, real world TCP, then scheduling.

Principles of Communications -- Michaelmas Term 2016....week 4 (to Nov 4)

Have  covered Sticky Random Routing (DAR material here) + Network Coding for TCP

see wikipedia for Gaussian Elimination, + Linear Network Coding articles - best source/explanation I can find

And Open Loop Flow Control (including leaky bucket regulators/policiers)

Next week, closed loop/feedback control, and underlying theory for controller design and stability/efficiency analysis.

Principles of Communications -- Michaelmas Term 2016....week 3 (to Oct 21)

Done centralised/hybrid routing/fibbing -- as someone pointed out, forwarding continues if a central controler caches - depends on timeout in openflow added state/fib entries - with fibbing, the timeout will be whatever OSPF Or equiv does - so a comparison is potentially a bit more subtle than as presented.
Also, SDN/Openflow lets you add entries based on 5-tuple, whereas fibbing lets you add by destination only.....so potentially more fine grain choices in SDN, even if at the cost of more state - so the "prefix hijack" in fibbing is neat, but not the last word in adding custom routes...(e.g. if you wanted by source, needs more state than can be added by fake Link State Advert - as far as I can see)

rest of week was on BGP - why, what, how, where, when, and why not!

Principles of Communications -- Michaelmas Term 2016....

Finishing up end of week 2 (lecture 4) with Compact routing
having done background graphs & reminder of routing basics.

See the  slides page for lecture material + links to papers with more detail if you want (where not covered in books -

I've also added some more pointers to background book like reading on the course materials page for people that want to read more around the area, as there's no specific single book that covers all the course materials.

ttfn

fairness, machine learning, versus optimal stopping and cognitive bias

There's a bunch of work in making sure that machine learning systems are, in some carefully defined sense, fair - see for example the MPI work by Krishna Gummadi, in removing biases in various ML use cases (e.g. gender as an explicit or implicit discriminator).

For me there's a really subtle problem here which links between this work and other problems of Optimal Stopping and Cognitive Biases, and how one choose to define fairness in ML and the feedback loop between this and human society and the views we take on each other.

So lets take two simple use cases:

1. Admissions to University and Gender

Imagine a Computer Science department has 100 applicants a month, over 3 months for 50 places and wants to pick the best 50 people. Naive use of Optimal stopping would say wait til you have 37% of the applicants (111 people), then pick. What if the population is drawn differently by gender - e.g. out of every 100 applicants, only 1 is female. Lets say this is because applicants are self selecting based on the position in the ability of their own sub-population.. You have about a 1/2 chance of having 0 women in the admissions. The feedback to the population in society is you have to be in the top 1% of female applicants, but in the top 18% of men. Assuming their isn't actually a gender basis for ability distribution. You've just built a system that re-enforces it. TO get out of this, you have to run a two-factor optimal stopping scheme. If you want to do this for other groups in society, it will get more complex too...

2. Stop&Search and Race

It may be the case that you stop and search people in safeguarding society by profiling individuals based on past cases of stopping and successfully apprehending miscreants. Lets say this leads to a higher probability of stopping people who "look middle eastern". Again there's a feedback loop between your "correct" but naive selection scheme, and how people behave - in this case, various cognitive biases in how society will regard the group you target, may lead to the group being marginalised, out of proportion to even your allegedly accurate statistical model. e.g. anchorism....or many others, will lead to over-weighting by society, especially since humans are risk averse.

sigcomm 2016 #2 - what worked well

a number of things about Sigcomm 2016 were really smooth, and i''d like to say what those were and why, for future reference

1/ a large number of volunteers did a meet/greet/arrange transport from the airport to the conference venue & hotels site - this was great - even delayed planes had a person with local knowledge 9of language/culture/taxi/etc) and so many panic moments were averted-  for example there were two flights from north america which were disrupted but people still got met - also
several people were severely mis-advised by airlines that their checked bags would go through from the international to the regional flight (this isn't the case in any country in the world that I know of, but united and tam managed to tell people this, despite that security demands passengers and bags are reconciled per flight) - nevertheless, with some local help, bags were retrieved within a day....

2/ the conference venue has a LOT of rooms and is very conveniently laid out so that almost instant access to coffee/lunch areas, and between rooms was very very easy. - the space is pleasant, acoustics are good, audio/visual (mikes/PA/speakers) worked well (including for remote speakers and for Q&A) - there are 6 main rooms next to the catering area, plus the large auditoriam area up one floor, with large bathroom area next to both, too - the groundfloor rooms can be reconfigured to 3 larger rooms - this is necessary as the 5 days of Sigcomm these days include
multiple tutorials and workshops on the monday & friday, plus multiple other events like the student research, the topic preview sessions, mentoriing meetings, and various committtee (sigcomm exec, next year handover)....all rooms were used most the time...

3/ many sponsors attended and several had desks for info for possible employment etc, out in the large catering area...

4/ the conference banquet (tue) and student dinners (wed) were both fantastic events - the former was 8 minutes walk from the conference venue, so people could get bak to hotels at their own leisure - the latter was a bus ride away - coaches whisked us there and back in about a half hour, and that was probably rhe best meal I have ever had at a sigcomm conference. The reception on monday (in the main conference auditorium) was good.

5/ there were a couple of pretty good local restaurants at the venue for people looking for socialising on the other days (including award winners dinner, N2women dinner +  for people arriving early, plus on the thursday nite)

6/ there was fairly seamless interaction between webmasters, and a/v team, so slides, papers, other access (e.g. to printers for boarding passes, for travel info/asking for taxis back to restaurants/airport etc) was all pretty painless

we had a day of wireless outage, which appeared to be on part of the internet not inside the conference venue site, but an engineer did come and fix it that day - this disrupted the live streaming (although we hope the recordings will still have worked and will soon be available via the ACM digital library links)

7/ the remote presentations were remarkably successful - this was because
a) the actual talk was a pre-recorded video, pre-shipped to us, so didn't depend on the net working well in realtime
b) most presenters had prepared lively talks with a super-imposed video of the full standing figure of the speaker, alongside the slide show
c) the talks all had a live Q&A (relying on skype/telephone call out as a backup of the internet was down) so there was little difference in terms of presentation between the remote presentation and local presentations in terms of human experience - indeed, several people commented that almost all the remote presentations were technically higher quality that most of the local ones....

8/ the size of the conference (approx 400 attendees) combined with the local relaxed culture was perhaps responsible for a very friendly atmosphere- I think this meant that it was a really fantastic experience for the (large number of) student attendees, giving many opportunities for mentoring moments and general exchange of ideas....a larger event might need slightly more formally organised mechanisms (certainly, last year's sigcomm in London with 700 attendees was a bit more of a "zoo").

9/ there was a lot of behind the scenes tech used to track all the organisation of things....this is available from the general chairs and other members of the organising committee (OC) on request

10/ the OC all carried out their tasks with incredible efficiency and timeliness. This matters as many of those tasks have dependencies  (e.g. travel grant, visa letters, or tutorial/registration/registration, or PC paper shepherding/web site program) - there are a couple of race conditions, but we had fixes....which requires everyone to be responsive (i.e. very day) and responsible....

thats all for now, folks...

sigcomm 2016 - so long & thanks for all the fishy behaviour

Sigcomm 2016 for me

As general chair, I felt I'd have to attend Sigcomm in Brazil, even though I 
had a co-chair who is local, in fact not least to give moral support for him.

However, for me, August involves my family holiday typically, and this year was no different.
So we'd booked a large villa in southwest france for 2 weeks for up to 20 people, so that the extended family (from
UK, Ireland, North America & Kenya and anyone else who wanted to drop in on their travels) could all be there.

So one week in, I had to head for the conference, taking a couple of the family with to get 1 to Berlin, 1 back to
london, (another couple were heading the other way from London to France at the same time...

Montpelier->Floreanopolis took about 30 hours (with a very good flight from LATAM for 830$ connecting in Sao Paolo
with only a 3 hour connection). I met a couple of people on the last 1 hour flight who had come from Beijing (one
poster & one paper author), who's journey was also about 30 hours, plus a couple of Europeans who had a journey of
about 15 hours - like mine would have been had I not been on annual vacation.


So while the conference, as a social event, and a technical piece of my day job, is really excellent (much
gratitude to the superb Brazilian hosts!), I missed a whole week of seeing my extended family, including some of them who 
I only see then, but won't til next year now.

So it is disappointing that a number of people who had papers to present (note, I didn't), did not attend. On papers
with an average of 5+ authors, they couldn't find one person to travel and present. The excuse was the Zika
outbreak. There is more Zika in some US locations than in the conference location, but hey, who expects everyone to
be rational. It seems also that many of these authors were connected with papers with Microsoft authors. Microsoft
were not a sponsor of the conference either (they have been in the past), despite having an author on 20% of papers
in the conference, and making a thing of this on social media. It seems that the conference has value as a place to 
get visibility for work of the company or student interns at the company, but not enough to have a presence (not 
even a recruiting desk at an event where there are around 200 junior researchers in networking, one assumes many 
of who are looking for interesting paces of employment next).

So for the first time we've allowed some remote presentations
at SIGCOMM - we had one live one in at the NetPL on day 1 because a 
speaker was held up by a plane failure and so managed to Skype in, 
but we had two on day 2 in the main conference paper sessions, which were
planned. Authors unable to attend ahead of time, sent in a canned video of 
their talk, then we skyped them in after for Q&A

The biggest problem with this is non-technical - its to do with the loss of community 
building opportunities based in hallway conversations triggered by the talk or other 
things th speaker/authors may have done that are of interest to attendees - this loss
is small for a small number of remote presentations, and in the case the remote
presenter is a student, probably worse for them than for conference physical attendees.
The loss is larger for the conference if the remote speaker is an experienced person
who might act as a mentor or offer useful feedback on other presentations,
live, in the other Q&A, or in hallways etc, if only they could have attended.
one simple example - the authors of the 2nd paper on the 1st main paper session day
differential provenance could interwork with authors of a paper on "light in the middle of the
tunnel" in hottmiddlebox on friday.

There's no advatnage to the primary author giving the remote presentation (rather than either anyone
else, or anyone else coming to present it in person) because no-one at the conference gets to
meet them anyhow, so they don't enhance theoir career any more than writing a Tech Report or putting a paper on 
ArXiv with a video.

There was some care taken (at extra cost to the conference organising committees) to get
decent videos and have them present (and esp. attention to audio both for speaker and for 
Q&A with the remote virtual attendee).

However, 3 semi-technical problems became obvious in the first 2 talks
1/ the speaker is canned - they can't adapt to audience attention, they can't re-pace
based on level of engagement, they can't change their presentation to account for other people's talks
or reference another talk where there's common ideas or differences - the speaker can't interact with the slides,
even pointing at axes to explain scales, or interesting features of a curve/anomalies, outliers etc....
2/ there's no obvious way in this model, to ask a speaker to "go back to slide 5" in the Q&A
3/ having a human figure in the projection who is larger than life (as would appear on stage) is an elementary
HCI fail.

On the 2nd&3rd day of the main conference we had quite a few more remote presentations. While they continued to be
well prepared, and the illusion of having the speaker in the room continued to be maintained by having a Skype
capability for Q&A at the end of each canned talk, the number was really stretching the credulity and patience of
many of us that out of 30+ distinct authors across that set of papers, 0 could get here. This continued on to
trying to have a handover meeting where the only people from 2017 able to be physically here on the lunchtime of
the last day of the main conference were people who were involved in the 2016 conference anyhow.

The event was no more difficult to get to than many past conferences, nor are there more real (rather than
perceived) risks about the location than many past locations.
[In fact, I attended last year in london to go to the handover meeting to learn the tasks required of us, so I
mssed vacation then too]

A lot of people went out of their way to make this a successful event, despite the lack of full engagement by many
people who obviously assume Sigcomm is worth submitting papers to for their career or their employers visibility,
but don't buy into the community idea. That's sadly shortsighted of them. They will be perceived as places less
interesting to go work for compared to those places that had a presence. Sad, because it has been incredible fun here and the local community showed up massively supportive, in huge numbers, and got a huge amount out of things. More loss for those who didn't make it here from north of the equator.

For those of us who took time out from valuable family life, took a lot of care about re-locating the conference to
deal with the public health issues with the original venue, it is doubly disappointing that there are people in our
profession who don't share our view of what the nature of the event should be. It is very unlikely that I shall 
bother attending again, or consider being on the PC if asked. I dont care to work for people who don't care.

unikernels & production

A recent blog called into question the fitness of unikernels for production. The title was a bit misleading as there are several unikernel  systems out there. some of which are actually in production - one of our faves is the NEC/Bucharest Uni work on ClickOS, for example, which is used for NFV on switches and is clearly a class act.

However, I think the article is also missing some of the main motives behind MirageOS (see e.g. Jitsu or the asplos paper) which was based in experiences with managing a lot of Xen based cloud systems - sure, Unikernels are specialised, and don't possess a lot of the micro-management/debugging tools (yet, although a lot are on the way) that you have for kernel debugging or system tracing of linux etc etc. But that's because OCaml real world experience in production was that you have faster system creation, and way faster debugging times. However, that's still not the whole story- the story is that the whole toolchain for managing source, building a unikernel, deploying it and tracing it is much more homogeneous - so a whole system of unikernels is easier to manage (as per previous experience).

Crucially, we are also able to verify some components of the MirageOS (e.g. Peter Sewell's group in cambridge did this (for some definition of "this") a while back for the TCP/IP stack, plus confidence about David and Hannes TLS implementation can be quite a bit higher than the "industry standard" that had 65 vulnerabilities in one year alone.

But all this is missing yet another key factor - unikernels don't replace xen/linux or containers - they play side-by-side with them, so you can have flexibility and familiarity, while affording better protection - that's in the Jitsu paper btw, and I thought was fairly clear.

Sure there's some way to go - there always is -there was when Xen first shipped too. But the computer science behind this is not that bleeding edge (nor were VMs back in Xensource's day either:-), but the science is 15 years further on, and we should all benefit from that, in my opinion. Indeed, it took a day to add profiling


xkcd has us in there thrice

readings in computer science found in a time capsule

recently, I was re-reading the classic old article on Smashing the stack for fun and profit in phrack, and wondering where the positive alternative lesson might be. Quite a while ago, I did a port of the SR(Synchronized Resources) programming language out of Arizona, to the newly minted RS6000 system out of IBM. The language is an elegant system for teaching principles of concurrency in lots of nice ways - at the time we didnt have a single agreed way to do it (e.g. wrong like in C11, or possibly ok in Java), so there was a need for a pedagogic approach and SR together with a nice book was very cool. However, we'd just bought a bunch of new IBM AIX systems with the new POWER PC RISC processor, which had a whole new instruction set - lets leave aside the amising idea of a "reduced" or "regular" instruction set that includes "floating point multiple and add" in its portfolio. However, in terms of registers, its a pretty nice system.

So why is porting SR to the Power CPU reminiscent of stack smashing, I hear you cry?
Because, you need to implement the threads system it uses to emulate real multi-core, I hear myself answer. And what does it take to do that, you continue? well you need to save the current context (like all the registers and thread state (i.e. PC, stack) move to a different thread/stack by calling the scheduler with a pointer to that context. To do this involves becoming familiar with the stack format used for most programming languages.as well as all the important (i.e. all) registers etc. So basically, slightly more than the Phrack folks....basically, writing stuff that moves to another exection context, but can get back again correctly, is harder:-)
You can see some nice examples of the context switch stuff for a variety of processors in the (not supported) SR archive

Meanwhile, I was also reading about the integrity check used for DNSSEC caches. so that will be reported elsewhere, but the interesting thing is that its a weak version of the IP header (and TCP) checksum algorithm. Again this is something that excercises computer science #101 - you need to add up all the 16 bit fields in the buffer (imagine you have a n byte buffer, then if n is odd, add a zero value byte and sum it as a vector of 16 bit values using "end round carry" (or ones-complement) artithmentic - basically, you have a 32 bit accumulator, and loop over the buffer. when you are done, you do one more thing - in the checksum case: check any bits above the 16 least sig are set, and fold them in (add again) and then do one more add in case that overflows too. In the integrity check case, just 0 any bits in the more significant 16 bits (i.e. && accumulator with 0x0ffff). For the ARM IP cksum case, see this
code with inline asm - the crucial bit's lines 78&79 after the bne loop.

amusing, back in the early days, i remember someone loop unrolling asm code for hte M68000 (that's not a 68020 or 68010, but 68000 - that was sold as a "Codata" computer in the uk, but was a Sun-1, i think, never sold by Sun) - the code went slower as the loop was now to big to fit in the miniscule instruction cache of said CPU...

hum...........what could possibly go oddly wrong with the allegedly simpler (by 1 instruction) integrity check algorithm? I leave that as an exercise for the coder

counciling the UK research councils

The UK research councils are unique in the way proposals are reviewed in several ways (in my experience)

firstly, unlike almost any other research funding agency (unlike DARPA, NSF in USA, CNRS in france, DFG in germany, the Japanese, scandinavian, and just about any other national funding agency I have dine reviewing for, which is a lot), the officers are not seconded experts so the assignment of reviewers depends on the reviewers self description - notoriously inaccurate. Unlike a journal (where the editor is an expert) there's not really a _peer_ review assignment process

secondly, the reviews can be rebutted by the proposer, but since the reviewers don't see each others reviews, they can't be calibrated against each other (unlike a conference or journal)

thirdly, the panel are not the reviewers and are not allowed to re-review the proposal, even if they are experts and only in exceptional circumstances will they discount an obviously incompetent or inappropriate review.

As a recipient of significant funding from the research councils, I am not expressing this through some sour grapes emotion, but more on behalf of my bewildered junior colleagues, who frequently receive inexplicably odd reviews and panel decisions. This is not good for community trust in the system - it may be ok at the obvious top 5-10% of proposals, but it results effectively in random decisions quite shortly after the very top (all 6s) ranked research. This is not good for confidence.

I can't give examples as that would be a breach of confidentiality, but everyone I know can tell a tale.

Maybe the new system after the recent review will involve people who have an answer to why the EPSRC and other councils should have a unique, and uniquely odd system. I have never heard an evidence based response to the comments above, which I have made several times to officials from the research councils. of course, since they themselves are not seconded from the community, how would they know, in any case. However, they could try talking to colleagues in other countries a bit more and see what works (or not) to persuade us that this is not just some random "we do it this way because we always have done"...

Part II Principles of Communications, 2015, to Dec 2

Wrapped up Traffic Management, including
idea of signaling protocols, and
space/time scales of different techniques;
and review of the course contents.

Planning to do revision classes next term.
Supervision notes will be linked to course web page after end of term.

[systems structures lecture moved to background]

some notes/problems from supervisions added
now

Part II Principles of Communications, 2015, to Nov 27

This week is

• Shared Media
• Mesh Network Capacity
• Coding and Multihop Radio (Cope)

Two useful network coding primer and coded storage articles...
and just what is a shim?

Part II Principles of Communications, 2015, to Nov 20

this week, covered scheduling, work conservation, max/min fairness, and PGPS approximations + queue jump!

Part II Principles of Communications, 2015, to Nov 13

Optimization (Nov 9) - background paper:-

from Princeton group

TCP in the wild - Optical Carrier Speed
table + Reminder about R-squared

Schedulers&Rounds....up to WFQ.

Part II Principles of Communications, 2015, to Nov 6

Flow Control, Congestion Control,
open and closed loop systems

Control Theory -
time domain model
transform to frequency domain
recipies for laplace transforms
stability & efficiency
proportional, integral and differential (and PID) controllers.

Online slides (PPT and PDF) are ok -
apologies for symbol/font problem in some of the printed pages!

Part II Principles of Communications, 2015, to Oct 30

Previously, Compact routing, Central routing (fibbing to link state),&path vector

This week covered
interdomain routing, including AS paths and deadlocks,
for which see interdomain revision notes/slides
+
multicast,
+
random routing

Just started on error and flow control.
[As usual, wikipedia is great on gaussian elimination ]

Pretty much as per schedule

Part II Principles of Communications, 2015, to Oct 23

This week has been about inter-domain routing, and BGP.
Covered background business relationships (peering, customer/provider etc), the protocol, the attributes/selection, SPP, and discussed scaling, convergence, and problems (like bad gadgets, wedgies) - as always, data is out of date, but Geoff Huston to the rescue...

Part II Principles of Communications, 2015

This week (to Dec 16) I should have covered the graph material (random graphs + alpha&beta models of small world/clustered graphs), and
Compact and Centralised routing - viz
http://www.cl.cam.ac.uk/teaching/1516/PrincComm/slides/schedule-2015.html

On graphs and networks there's a new really nice book by Jon Kleinberg


There's some lack of precision about the terms "small world" but basically, (wikipedia is your friend) a scale-free network refers to the power law degree distribution, and consequential small diameter (and some clustering), which leads to the small world property. Not all small world networks are scale free, but scale free networks are small world...

The Smell of Memory

scientists in cambridge have recently figured out how to code the smell of memory, not just a smell of one thing that evokes a particular memory, but the underlying phenomenon that is memory itself. It turns out that it is not so abstract, and that there are only really 7 key parameters (somewhat like taste, which is, of course, related to smell in any case). Working backwards from the examples of smells that evoke memories, using a statistical technique called PCA, scientists can now code the entire space that is memory - so not only evoking a particular memory, but replaying everything at once.

Of course, there are severe dangers of synaesthesia with this technique, so it will only be allowed in key, socially beneficial situations, such as court cases, or TV interviews with politicians.

And it must be noted that there will inevitably be people who have an innate fear of smell - loosely related to the smell of fear, but far more disabling in this context, except where you'd like the right to be forgotten - de-oderant amnesia.