All I Really Need to Know I Learned from TCP/IP
1. To Share
TCP shares bandwidth with other TCP sessions. In TCP there is a function that reduces packet output when the network is congested. It is because of this ability to share that the present day internet is usable by so many people at the same time.
Likewise, in the real world, scalability increases through sharing, not through unreasonable competition.
2. Trust is built on repeated acknowledgment
TCP ensures trust by sending Ack(Acknowledgment) packets to notify data arrival. While the TCP session is running, Acks are repeatedly sent and received. It's not saying to much to state that this repetitive process of acknowledgment is the basis for trust.
Likewise, in the real world, a repetitive acknowledgment process is very important. You just can't trust people won't reply to or even acknowledge emails you send them.
3. Long periods of no communication will kill a relationship
With a TCP session, if a period persists where there is no packet transaction, the session may expire. The session can expire if the two end points acquire a "Closed" TCP state, but more likely, if there is NAT (includes NAPT, IP masquerading) router in the middle, the conversion tables may be discarded in 30 seconds or so.
Likewise, in the real world, if communications cease for too long, your status may deteriorate to "stranger".
4. A state of fine fluctuation is actually quite stable
With TCP, a stable data transmission often means repeated cycles of increasing and decreasing data flow. This fine fluctuation of data flow, when seen from a macro perspective can often be seen to be "stable".
Likewise, in the real world, "stable" rarely means a completely fixed state, but rather points to a state of repeated minute fluctuation when looked at, at a micro level.
5. It's much more efficient to answer things all at once than 1 by 1
Instead of sending an Ack to each and every single packet it receives, TCP sends a collective Ack after collecting a predefined number of packets. Sending an Ack for every individual packet would be extremely inefficient.
Likewise, in the real world, people dislike being answered in mince meat fashion. It is recommended that you figure out the underlying meaning behind a series of questions and answer them together.
6. Things work more efficiently if you inform others ahead of time how much you can handle
TCP starts by informing the sender how much data it can handle. This is referred to as a "window". The sender then sends data in amounts that fit within the window.
Likewise, in the real world, it is much more efficient if you can inform others of how much work load you can handle. If you accept more work than you can actually handle, you will cause problems not only for yourself but to the other party as well.
7. Windows should be opened a little bit at a time.
Generally the TCP algorithm starts with a small window. If no congestion occurs, then the Window size is gradually increased.
Likewise, in the real world, when dealing with new people, your "window" of trust doesn't start out fully open, but instead gradually opens up more and more as you get to know the person.
8. "Hiccups" will cause a window to close
Generally TCP will cause the window to shrink when experiencing packet congestion. When the window shrinks, the data flow decreases, allowing the congestion to clear up.
Likewise, in the real world, if you experience hiccups in your relationship with another person, your window of trust toward that person will shrink.
9. Some people go for quick and easy rather than reliable
When the internet was first designed, it was thought that reliable transmission was sufficient and a non-reliable transport protocol was not needed. This can be seen by the fact that the TCP IP protocol number is 6 while that of UDP is 17.
However, in transmission types like voice transmission, where "immediacy is more important than reliability", it is better to keep going even if you lose a few packets along the way.
Likewise, in the real world, it is also sometimes better to steam ahead rather than take your time to build trust before starting out.
10. It's hard to build anything where there is no trust
Non-reliable transmission methods are necessary, but programming for a transport layer without reliability is very difficult. For instance, in voice and video transmission using UDP, it is necessary to have a scheme like FEC(Forward Error Correction) to supplement dropped packets, a method to discern whether packets have been dropped in the first place, and a scheme to deal with packets arriving out of sequence.
With TCP, these factors do not become a concern. So it seems to be true that it's hard to build anything where there is no trust.
11. One person not willing to compromise will screw things up for everybody
TCP ensure scalability by having everyone willing to compromise and share resources. It may well be because of this spirit of sharing built into TCP that the internet doesn't break down even when so many people all over the earth use it at the same time.
However, in this world of sharing, if a UDP stream which does not share at all (caused by the likes of a DoS attack) comes crashing in, TCP gives way to UDP. The non-sharing single UDP stream basically pushes aside multiple TCP streams.
Likewise, in the real world, sometimes a single individual will force his/her way through causing problems for everyone.
12. Distance matters
According to Sally Floyd, the maximum sending rate for a TCP connection can be described by the equation below. (refer to: Promoting the Use of End-to-End Congestion Control in the Internet, Sally Floyd and Kevin Fall, IEEE/ACM Transactions on Networking, 1999, http://www.icir.org/floyd/papers/collapse.may99.pdf )
- T: sending rate
- B: MTU (Maximum Transfer Unit)
- R: RTT (Round Trip Time)
- p: packet drop rate
- B: MTU (Maximum Transfer Unit)
You can see from the equation, that the bigger the value of R or RTT is, the lower the TCP sending rate becomes. Because the speed of light is a finite thing, generally speaking, the farther apart you are, the lower the TCP sending rate becomes. (Of course the type of physical layer and/or number of intermediary routers can be a strong factor too.)
If even TCP is affected by distance, it's impossible to imagine real world relationships not being effected by distance as well.
13. When you are far apart, use multiple channels
When distances increase TCP's data transfer ability deteriorates. The most common method of circumventing this issue is to increase the number of TCP sessions. For instance in HTTP it is common to create multiple TCP sessions to attempt improved throughput.
Like wise, in long distance relationships, instead of using just the phone, if you set up multiple channels of communication, it is thought possible to improve the situation.
14. (Unspecified || specified) multiple entities are hard to trust
TCP is 1 on 1 transmission. On the other hand, multicast is transmission with multiple entities.
It is possible to retain reliability with 1 on 1 communication using TCP, but extremely difficult to do so with multicast. It may not be impossible, but in most cases it will mean using an extremely complex scheme of some sort.
Like wise in the real world, it is easy to trust a single person, but to trust a group of people is a harder thing to do.
15. If you don't know, ask a neighbor who might
With packet transfers taking place in routers, it is a repeating cycle of comparing the destination with routes that you know and forwarding on to the next router. Each router may not know the destination of the packet, but may know someone who does. In this way, by letting routers depend on neighbors who know what they don't, scalability is maintained.
Likewise in the real world, it is extremely useful to know someone who knows something.
16. A default "go-to" can make a big difference
All the routers connected to the internet do not have information about all the destination networks. So if one router doesn't know, it relays the packet through a default route to a router who knows more than itself.
Likewise in the real world, it is a great thing to have a default
"go-to" person who can advise you when you are in real trouble.
17. Depending on how you phrase it, you can link anything to life
Yup, just like this article!
This is an english translation of my japanese written blog article. http://www.geekpage.jp/blog/?id=2008/1/29
Inspired by : All I Really Need to Know About Pair Programming, I Learned in Kindergarten, Communications of the ACM, Volume 43 Issue 5, May 2000, Pages 108-114
