Hacker News new | past | comments | ask | show | jobs | submit login
Understanding computer networks by analogy (2000) (memo.mx)
73 points by asicsp on March 10, 2023 | hide | past | favorite | 7 comments



I use a very similar analogy except it's either a meeting room with many people or an open floor that is the subnet. It helps explain BUM (Broadcast, Unknown Unicast, and Multicast) traffic in a more natural way e.g. ARP is you walking into a cube farm and shouting "is Jeff here?" and then he raises his hand so you can deliver the latest printouts directly to him without disturbing the others. In that case the individual is the IP, the cube floor is the subnet, and the higher level analogies are the same.

The BAS relation for SDN is interesting. I've always avoided any analogies with SDN since different people have different ideas on what qualifies as SDN or what SDN is going to do but that's a really good choice given the rest of the analogies.


Good analogy. I had started to think ip-addresses as phone numbers, and it had started to make sense for me. Using Building, Floors, and providing analogies for interfaces, switches and routers were good.


For more analogies see the link below.

This little project was developed I believe within a Google team, with more analogies to help you understand certain concepts, or explain them easier for your less technical comrades.

Enter at your own risk, ATM it comes up as unsecure website.

[0] https://sidewaysdictionary.com/


To me the thing that is difficult to wrap my head around is how congestion control, back pressure, and buffering at various levels work. It feels almost magical that somehow I can download stuff from various places and the bandwidth of different streams work out efficiently without much explicit coordination. And then there are things like bufferbloat.


> To me the thing that is difficult to wrap my head around is how congestion control, back pressure, and buffering at various levels work.

Snarky answer: that's because they don't.

Attempts at humor aside: It really helps to understand a bit about queuing theory to wrap your head around these things. Each packet being an independent event has some unintuitive consequences. Each switch or router or etc (middlebox) in the path from one endpoint to the other adds the packet to a queue (which is what the buffers are), and that queue may be filled by other flows coming into the middlebox from different ports.


In my experience, all the fancy protocols doing fancy things are rarely used. I used to work for one of the leading network vendors and they couldn't make CEO speech stream not lag horrendously while selling solutions to this exact scenario.


All analogies eventually break down and end up doing more harm than good. Just teach the topics well. Part of knowing something is being able to communicate it effectively to others.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: