p.23:
Fig. 1.15 would depict something like the SABRE airline reservations network mentioned on p.20. Note the use of multidrop lines, mentioned in our printed lecture notes unit with that term in its title.
p.24:
Be careful the term datagram is generally used to connote a connectionless communication. For that reason, it pops up in two different contexts:
p.27:
The term state information refers to, for example, TCP connections. During the initial steps of establishing a TCP connection, the connection is in one state, then it changes to another state during the actual data transmission, then to another state when the connection is being shut down. By contrast, since communication between Internet routers occurs on a one-time basis, i.e. no "state" is recorded for communication between routers, we say that they are stateless. Without this, upward scalability of network size would be very difficult, since each node would need to record information about many different connections.
The "end-to-end mechanisms" mentioned here are exemplified by TCP, i.e. mechanisms which set up sessions between an end source and an end destination.
p.28:
The phrase "...complexity is relegated" makes the point that by keeping IP simple, we keep the Internet simple. Again, by placing the complexity in the upper layers like TCP, only the two endpoints of a connection need handle complex operations, with the intermediate nodes being simple.
p.45:
Step 7 in the table may be surprising, but it's true--the transaction is done. When you go to a Web page and perform various operations with mouse clicks, you perceive that as being all part of one large HTTP transaction. But the fact is that each of those operations is a separate HTTP transaction, independent of the others. So even HTTP is "connectionless."
p.59:
In reading the word "datagram" here, see the notes for p.24 above.
p.60:
"Strictly speaking, the IP address..." The reason for this phrasing is that a given machine could have more than one IP address (with more than one NIC)."
p.61:
In Fig. 2.13(a), note that the PPP connection (which is what you usually use, for example, in connecting your PC at home to an ISP) is also a "network," just like an Ethernet is a network, even though the PPP connection will consist of just two nodes.
In Fig. 2.13(b), note the lack of a TCP layer in the router. This would be the case, for instance, in a dedicated router such as those produced by Cisco. It would not be the case if our router were merely a PC or a workstation, since for example we may wish to send e-mail or use the Web from that machine. (Actually, even a Cisco router probably has a TCP layer anyway, just for diagnostic use.)
p.133:
This material at first looks a little intimidating, but it is really not hard at all. It is helpful to first look at pp.111-112.
In Equation (1), p.111, the original signal was x(t) = cos(2 pi ft), and y(t) is the transformed version of that signal when it is passed through some communications medium. (This could be as a result of a deliberate transformation, as in the case for instance of AM radio, or the result of distortion due to the imperfect nature of transmission through some medium.) The analysis here models a change in amplitude of the signal--which was 1.0 in the case of x(t) but is now A(f) in the case of y(t)--and also phase, meaning a shift in frequency.
It is very important to note the `f' in the amplitude change A(f). The point is that in a channel which distorts a signal, the distortion will be worse for some frequencies than others. In particular, some frequencies will be transmitted in more weakened power (i.e. smaller A(f)) than others.
That weakening is called attenuation. It is measured by the quantity d = 10 log10 (Pin/Pout), where we are taking the log of the ratio of the power of the original signal to the power of the distorted signal. The name of the units used to describe d is decibels. The range of frequencies for which the communications medium has low attenuation is the effective bandwidth interval for that medium.
p.137:
Note that in the second paragraph the authors are informing us that (many years ago) the telephone company decided to limit the bandwidth of the transmitted voice signal to 4 MHz, in the following sense:
Your area code and the first three digits of your phone numberdetermine. which local switching office your phone belongs to. The line from your phone to the local switching office is probably a twisted pair. If you call a phone which also belongs to this switching office, it is switched through by that office. But the calls you make to other phones must travel through trunk lines between one switching office and another (or through higher levels of a hierarchy of switching offices). The trunk lines use FDM, with each channel having bandwidth 4 MHz. That value was chosen simply because it was the effective bandwidth of human voice.
The phone wires themselves actually have higher bandwidth, and more modern techniques like DSL allow you to take advantage of those higher bandwidths.
p.158:
Note that these "words" are merely chunks of our message, artificially chopped up. Say for example we have an 80-bit message. We chop it into 16-bit chunks, of which there will be 5 (so L = 5). We then add the chunks to produce a 16-bit checksum using Steps 1-3 on p.159, appending it to our original message to make a 96-bit message. By making the checksum equal to the negation of the sum of the message words, the entire extended message will have sum 0. Thus the receiver need only do the sum and check whether it is 0. (If it is not 0, the receiver knows there was an error.)
p.159:
When the authors talk about the 2-bit distance between a valid codeword and its valid-codeword "neighbor," their point, which they don't make explicit, is that 1-bit errors will definitely be detected. Here is why: The sender sends valid codewords, while the receiver may receive either valid or invalid codewords. All the valid codewords are an even-numbered distance apart from each other. Yet if there is a 1-bit error, the resulting codeword will be a distance 1 away from the transmitted one, and thus cannot be in the set of valid codewords. Thus the receiver will know that there is an error.
p.165:
Here n (from p.161) is the number of bits in our message, including the CRC field. (So n here is our m+c-1.) So the error polynomial e(x) [which we call E(x)] has degree n-1. Thus j < n, and since i < j, we have that i is between 0 and n-2, inclusive.
Their description of a primitive polynomial is jumbled. Here is the same thing, reworded: Say we have a polynomial p(x) of degree N. If p(x) has the property that it does not divide xm+1 for any m < 2N-1, then we say that p(x) is a primitive polynomial.
p.166:
When the authors say "all code polynomials," then mean all W(x) in our notation, i.e. all possible messages (including both the original message plus the CRC field, m+c-1 bits in all) formed under the CRC method. What they are saying, then, is that if we can find a C such that all Ws generated from that C contain an even number of 1s, then any E with an odd number of errors will be detected. But how do we find such a C? Surprisingly, all we have to do is make C(x) include x+1 as a factor. Here is why:
Suppose C has that property, i.e. C(x) = (x+1) h(x) for some h(x). Recall that any W(x) will be a multiple of C(x); that is the way CRC is set up. But then that means that any W(x) will have (x+1) as a factor. That in turn means that W(1) will be a multiple of 1+1, i.e. W(1) = 0. But as the book points out, W(1) = 0 means that W must have an even number of 1s.
p.276:
Note that we essentially have a window size of 2 here. Because of the "ambiguous ACK" problem they describe here, in ARQ protocols we always need a window size which is 1 larger than N. For Stop-and-Wait, N = 1, hence the window size of 2.
p.311:
For details on the byte-stuffing, see p.337.
In Figure 5.40, suppose we have a TCP/IP connection to an ISP via dialup from a PC at home. The Protoocol field would contain 0x0021, the code for IP, and the Information field would contain the IP datagram itself.
p.313:
Here is what is going on with CHAP. Say you will be frequently logging in to some computer remotely, say through the Internet using telnet. If you are worried that a network eavesdropper will see your password when you log in, CHAP can make this almost impossible.
When you log in, CHAP on the host end will send you a random number. CHAP on your end will plug that number, together with the password you type, into some encoding function. The encoded value is then sent through the network, and decoded by CHAP on the host end. CHAP on the host end will also take the password it has for you in its records, and plug it into the same function using the same random number. If the two encoded values match, CHAP lets you log in. The point is that even though the eavesdropper may see your encoded value, he has no way to recover your actual password from it.
p.361:
The authors say, "For very small values of _a_, Non-Persistent CSMA has a relative high maximum achievable throughput". Here is why:
At any given instant, either (a) no one is sending, (b) two or more nodes are colliding, or (c) one node is successfully sending. To get large throughput, we need to have the proportions of time in which (a) and (b) occur to be small.
The small value of _a_ means that we have (b) small. (a) will be small as long as we have lots of nodes.
By contrast, with a 1-persistent protocol, (b) will be rather sizable even if _a_ is small.
p.365:
The "reaction time" here is the time it takes a node to discover it has been involved in a collision. This can be as long as tprop.
p.399:
It is not clear what propagation speed they are assuming here. Note also that 1210 should apparently be 210.
p.400:
6.44 should be 5.44.
They are assuming just one frame sent per busy period. This gives them a lower bound for the utilization. (They can't do any better than this, as they don't know the mean number of frames per busy period under the conditions of maximum utilization.)
The values 0.94 etc. come from plugging in `a' into the formula.
p.409:
Note that in light traffic, Ethernet would give a lower delay value, since a node can send immediately. Token ring does better than Ethernet in heavy traffic, since we don't waste bandwidth with collisions and backoffs.
p.414:
It looks odd here in the discussion of FDDI's "elastic buffer." First the authors describe it as being 10 bits long, but then suddenly switch to 5. The discrepancy is resolved by the additional information (not shown) that an FDDI node will allow 5 bits to accumulate in the buffer before starting to remove them and process the frame. (When it does start to remove them, bits may still be coming in, so we have another 5-bit space for "wiggle room.")
Also, a "symbol" is a transmitted bit, as opposed to a data bit. In 4B5B coding, there are 5 symbols sent for every 4 data bits.
p.415:
IEEE 802.5 is the token ring standard. See p.413.
p.444:
Here "distance" is defined in terms of the number of LANs traversed.
Here is an example for Fig. 6.87. Let Bi.j denote port j on bridge i. Say Node A on LAN3 wants to send a frame to Node B on LAN4. Thedesignated. port for LAN3 is B3.2. B3 knows (having gone through a period of address learning) that Node B is on LAN4, via B3.3. So, B3 accepts the frame for copying, and forwards it to LAN4.
On the other hand, say Node A wishes to send to Node C on LAN2. Again, B3 is the designated bridge and thus will be involved here too. In this case, B3 will copy the frame to B3.1, which takes the frame to LAN1. Then since B1.1 is the designated port for LAN1, B1 copies the frame to B1.2 and thus to LAN2.
p.463:
The reference to "network scalability" is about size -- does a given policy work well (i.e. "scale") as the network grows? The less functionality there is in the Network layer, the better the scalability.
p.472:
An example of an "interconnection fabric" is the Omega network discussed briefly on p.5 of our printed lecture notes unit on Level 2 switching.
p.481:
Instead of a packet giving a destination address in its header, it simply states which output port it should be routed out at the next router. Each router changes this field to set up routing at the next router. Note that all this is possible because a fixed route for all packets is set up at the time the connection is made.
p.495:
First, note that Table 7.3 has some errors. All of the entries (3,*) in the Node 3 column should be (2,*).
When the link from Node 3 to Node 4 breaks, Node 3 at first still hears from Node 2 that the best path from Node 2 to Node 4 has cost 2. This is actually out-of-date, incorrect information, but Node 4 doesn't know this, and it is desperate to find a path to Node 4, now that it knows its own direct link to Node 4 is broken down. So Node 3 says, "Oh, I see that I can get to Node 4 by going to Node 2 as my first step (and then follow directions from there), for a total cost of 2+1 = 3." That is incorrect, since Node 2's information relied on a path to Node 4 through Node 3, which is no logner possible! And then it gets worse, since Node 2 will next udpate its own table with the wrong information it receives from Node 4.
p.518:
The phrase "datagram networks" is a reference to IP and the like.
p.520:
Here I and L are design parameters, i.e. set by the designer of the system in an attempt to achieve certain performance goals.
p.572-573:
There are a number of things which must be clarified here.
First, there are several references to the "applications" on both ends. An example would be that the sender is running ftp and the receiver is running ftpd. Here the sender would be uploading a file to the receiver. For concreteness, we'll assume all this here.
In the Send picture in Fig. 8.19, earlier bytes appear on the left, later bytes on the right. Remember, earlier bytes have smaller sequence numbers.
WS is the size of the sender's buffer, i.e. how much buffer space the TCP/IP stack at the sender has allocated for this TCP session. It includes both the bytes which have been sent but not yet ACKed (bytes Slast through Srecent in the picture), newer bytes which have recently put in the buffer by ftp and space not occupied yet (bytes Srecent+1 through Slast-1).
Each time the receiver ACKs some bytes, Slast increases. Every time the sender sends some bytes, Srecent increases.
Each time ftp sends some bytes, the number of "not yet occupied" bytes decreases. However, note that if there is no more room left in the buffer, the TCP/IP stack will not allow ftp to do any more writing; ftp will simply hang (in a call to write() or sendto()) until the receiver does an ACK and thus frees some room.
There are a couple of typos in the Send picture in Fig. 8.19: Wa and Ws should be WA and WS, respectively. Note that "octet" means byte.
On the receive side, the text description of Rlast is wrong; it is correct in the picture. Note that "the application" here is ftpd.
p.583:
The number 232 should be 232.