cs398 Lecture Notes Spring 2000 Week 2, Tuesday Reading that was due today: P&D Section 1.2 You should have prepared answers for questions 5, 6, 10, 12, 13 Reading for Thursday: Section 1.3 (you can skip 1.3.3) plus, the Java Socket section of the Java Tutorial... http://java.sun.com/docs/books/tutorial/networking/sockets/ Homework #1, out today, back next Tuesday. Groups TBA. Quiz Thursday on Chapter 1. Resource-sharing ---------------- Taxonomy of multiplexing: 1) frequency-division multiplexing 2) time-division multiplexing a) synchronous b) statistical Why is a data stream divided into packets? Challenges for statistical time-division multiplexing? Fair allocation, handling congestion. What is the fundamental limitation of both FDM and STDM that makes them inappropriate for Internet traffic? (See question 10) Section 1.1.3 The semantic gap ------------- Network provides basic capabilities defined by the hardware. Many applications have common higher-level requirements. OS can fill the gap by building virtual/logical capabilities on top of hardware capabilities. Example: reliability Networks are fallible (three kinds of errors) Software can 1) detect/correct corruption (bit and burst errors) 2) detect/resend lost packets (full queue drop) 3) detect/maybe deal with machines and links that are down Example: performance guarantees Can software make promises the hardware can't keep? Maybe not, but it can figure out what promise to offer. Section 1.1.4 The two parameter model of network performance ------------- The vocabulary in this section is a nightmare, in part because the authors make bad choices (in my opinion) and in part because most of these words get used in different ways. In general, I am just going to avoid ambiguous words altogether. Here are the definitions we will use in this class. trip time = propagation time + transmission time + queue time propagation time is the fixed cost of sending a packet, regardless of size. propagation time = distance / signal speed propagation time is largely determined by the distance of the link and the speed of the signal in the link, but there are other factors that we are ignoring for now. transmission time is determined by the rate bits can go onto or off of the link, so it depends on the size of the packet and the bandwidth of the link transmission time = packet size / bandwidth Here's an annoying thing. Packet size is usually in B, KB or MB bandwidth is usually in Mbps or (less often) Kbps I find it most convenient to translate packet size into bits and work in bits all the time. That allows me to deal with the (power of two vs. power of ten) problem at the same time. (See questions 12 and 5). Figure 1.9 is an excessively-complicated way to say the following: 1) for small packets, prop delay dominates 2) for large packets, trans delay dominates 3) for a given prop time and bandwidth, we can find a crossover size where prop time = transmission time 4) as bandwidth increases, this crossover point gets bigger (See question 6). What is the significance of the delay-bandwidth product? (See question 13). Flow control, congestion detection, and retransmission for reliability all require coordination between the sender and the receiver. Example: The receiver may be processing incoming data slower than it is arriving, and maintaining a queue of data waiting to be processed. When the queue is "full" the receiver sends a message that says "stop sending!" After the send, the receiver can expect up to one rtt-bw of data before the flow stops. What is jitter? Section 1.2 Layering and protocols ----------- (quote from page 30) "The idea of abstraction is to define a unifying model that can capture some important aspect of the system, encapsulate the model in an object that provides an interface that can be manipulated by other components of the system, and hide the details of how the object is implemented from the users of the object." To capture an aspect means that the model and the real world will agree with respect to that aspect. An object is an entity that provides a set of well-defined services. It may not be an object in the sense of a Java object (a set of data fields with a set of operations). It might look more like a bunch of system calls that you invoke, and that manipulate data somewhere in the kernel that you don't know much about. But that's an object. For example, you click on a hypertext link. The link contains two pieces of information, the name of the file and the name of the host containing the file. http is an application-level protocol that determines a coding for the message "send me the file named fred.html" maybe the message looks like GET fred.html actually, I have no idea what it looks like, but assume that's it. It is 13 bytes long. In theory, your browser could invoke the network card's device driver directly and put these bits on the wire. But: 1) when they got to the first internal node, how would it know what to do with them? 2) assuming it somehow got to the destination, how would the recipient know how to interpret it? 3) assuming the recipient somehow knew what it meant, how would it know where to send the reply? It would be infeasible for every network application to handle these problems themselves. That's why we need transport protocols. The fundamental transport protocol on the Internet is called IP (internet protocol). IP defines a global address space such that every node in the network has a unique address. When you transmit a message using IP, you attach a header to the message that is like an envelope. The header contains the destination address and the source (return) address. That handles (1) and (3). IP also defines a set of ports. A port is like a mailbox. A process can allocate a port and use it to send and receive data. Most network servers use a pre-defined, well-known port number. For example, web servers attach themselves to port 80. Web clients usually choose a port arbitrarily from the range of numbers that have not been preallocated. So the header contains: source IP address dest IP address source port # dest port # Internal nodes use the addresses to direct the packet to its destination. The destination host uses the dest port # to know which process to hand the packet to. The recipient process uses the contents of the packet to figure out what to do, and the source info to know who to reply to.