Chapter 1: Foundations
Although at times very general, there's a lot of concrete bits and pieces
here in the first chapter. You should read it through, but with an eye
towards figuring out how a "basic internet" might be put together.
The standard "basic internet" consists of a bunch of Ethernet "local
area networks" (LANs) (probably bridged Ethernets; we'll get to these)
joined together with telephone-company-provided point-to-point links. (In
the "real" Internet, there are other LAN types, and a wide range
of phone links, and some hybrids like ATM.) Keep this model in mind as
you read. In this model, as in the real Internet, routing about the LANs
and links is done by the Internet Protocol (IP) layer; a full discussion
of this forwarding algorithm is found in chapters 3 and 4.
Section 1.1
Section 1.1.1 deals with some basic ideas about LANs: connectivity, switching,
and falling back on the "cloud" abstraction whenever convenient. Perhaps
the most important concept here is that of switching and addressing.
Study question, 1.1.1
Describe the connection between switching and addressing. Which comes first?
Section 1.1.2 deals with sharing links. A couple alternative ways of
doing this are presented (STDM and FDM), but the real point of this section
is to introduce the idea of packets, and then packet switching.
Study questions, 1.1.2:
Why do we use packet switching so universally?
How are packets related to addressing?
Section 1.1.3 deals with communication patterns. The most basic is that
of a reliable stream connection, which is exactly what TCP is all
about. TCP is used for file transfers, the web, email, and lots of other
things. However, TCP doesn't work well with audio and video, and this section
explores why. There is also some discussion of reliability, and the gulf
-- as it were -- between reliability at the physical link level (with an
inherent failure rate), and the very high reliability provided by TCP running
above that.
Study questions, 1.1.3:
Why doesn't TCP handle video and audio very well?
How do you get reliable transport running on top of unreliable links?
Section 1.1.4 deals with the tradeoff between bandwidth and latency.
As the world gets faster, bandwidth improves, but latency does not (why?).
There are a host of calculations that can be performed here for specific
examples of bandwidth and latency. Note in particular the discussion of
the Delay x Bandwidth product.
Study questions, 1.1.4:
What would networking be like between the earth and mars, with an RTT of
one hour (depending on astronomical positions)?
What would networking be like with 1Gbps bandwidth but 1.0 sec latency?
How would it be different from today?
Exercises:
13 (assume no final ACK is sent (section 1.1.4)
15 (latency calculation)
18 (latency calculation with a switch)
23 (general ballpark bandwidth estimates for various services)
27 (an attempt to illustrate bandwidth, latency, and jitter)
Section 1.2
Here we deal with the layer model. This is simply a way of abstracting
the lower layers of the network, whenever you want to focus on the higher
layers. One thing to get out of this is that the OSI "7-layer model" (discussed
in the chapter) has more to do with politics than reality, although most
of the layers are useful abstractions. Another important idea is that layering
is literally a graph, not a linear relationship. Also, layering
has a very close connection to headers: generally, each layer adds a new
header to a packet. One final point is that one needs some kind of layer
to handle addressing packets to specific "ports" on a given host, not just
to the host itself, just like mail needs to be addressed more specifically
than just to a given building.
Study questions:
Is it possible to do networking without a string of multiple headers?
How much do headers "cost", in terms of lost bandwidth? Is it worth
it?
Does anyone have a clue as to what the "Presentation" and "Session"
layers are for? Why not?
Exercises:
8 (kind of a "soft" question; don't expect a definitive answer)
20 (about headers, ultimately)
Section 1.3
Here is a sample "simpletalk" (or "simplextalk") demo program. It is "simple"
because it is not very complex; it is "simplex" because the communication
flows only one way, as opposed to "duplex". It is a good example of how
TCP programming works: connect() on the client side but first gethostbyname(),
while the server side has the tricky listen()/accept() model.