Subscribe

RSS Feed (xml)

Powered By

Skin Design:
Free Blogger Skins

Powered by Blogger

Showing posts with label networking. Show all posts
Showing posts with label networking. Show all posts

Tuesday, April 15, 2008

Q & A on Teoretical ANalysis of Router Systems

Q: Simple IP routers have only one FIFO (First-in-first-out first-come-first-served) queue for the packets. That has the drawback that some users may achieve much higher data rate than others, for example if their packets are long in average, if their TCP sessions have long duration, and thus they avoid TCP slow-start, and if the IP packets only traverse a few routers. That is not fair. To address this problem, modern routers support fair packet scheduling algorithms, such as the Weighted Fair Queuing algorithm. This means that each flow (=stream=session) of IP packets has its own FIFO queue, instead of one common FIFO queue. If we only consider best-effort traffic (without QoS guarantees), then the router controls that backlogged flows (with at least on packet in queue) get equal bit rate, independently of packet sizes, TCP session durations, number of passed routers, etc. If we consider several routers, all flows do not achieve equal bandwith, but the minimum bandwith that a user can achieve is maximized. This is called max-min fairness. (I hope my terminology is correct.)

A flow is identified as a unique combination of source and destination IP address and TCP port number. This mean that a user who simultaneously communicates with N different hosts, or N different TCP ports, will achieve N times higher data rate than a user who communicates with only one host and one TCP port. I.M.O., that is not fair. I think that if several packets goes to [from] the same IP host, and that host is situated in the same (sub)net as the IP router, then they should be considered as the same flow irrespectively of the source [destination] and the TCP port numbers. I haven't seen any discussion about it in scientific papers, or in CISCO knowledge database, so I guess that CISCO routers do not support this. Do you have some idea why?

In the academic world, a lot of other fair resource sharing algorithms are studied, such as deficit round robin, and algorithms for proportional fairness. Do you know if these algorithms are supported by routers existing on the market today?

A: You are correct that the academic world is overrun with theoretical studies of packet scheduling and traffic engineering. Researchers in the area of Performance Evaluation have had little impact in operating systems and databases; now they are applying the same techniques to networks. In fact, everyone I know who used to write papers on performance of something is now writing papers on performance of networks. Recently, I had a visitor in my office who told me he was shocked to discover that the academic work was almost completely ignored by industry -- engineers bulding switches and routers didn't find that the analysis worked in practice.

So, you are discussing a few details, when the important question is whether the whole scheme is worthwhile. Many of us in networking think that it is not -- scheduling will NEVER be a satisfactory solution to the resource problme. The notion of ``equal pain'' didn't work for operating systems, doesn't work for automobile traffic, and it won't work for networks. The only viable long-term solution is increasing resources (the ``big bandwidth'' solution).

Q & A on Application Level Gateways,

Q: Please could you help me understand this - how do application (level) gateways work?

A: An application gateway is a running program that connects two or more (heterogeneous) distributed systems. For example, one type of application gateway is used to connect heterogeneous e-mail systems. To understand the motivation, assume that you work for a company that runs proprietary e-mail software internally. If the company wants to send e-mail across the Internet, it must format the message according to the Internet standard and must use standard Internet protocols to transfer the messahe. An application gateway can be placed between the two -- the gateway accepts outgoing mail in the proprietary format, reformats it to use the Internet standard, and sends it. Similarly, the application gateway accepts all incoming e-mail, reformats it to use the proprietary system, and forwards each message to the appropriate recipient using the proprietary e-mail system.

Q: How are they related to ip packet filtering.

A: Application gateways are seldom used to perform packet filtering because the overhead is high (each packet must be transferred from inside the operating system to the application gateway and back into the operating system for transmission, and there is usually a context switch as well). Thus, most packet filtering is performed by a router or by protocol software inside an operating system.

Q & A on Ethernet Transceivers and "10BaseT",

Q: I had a few questions regarding ethernet ..

Unlike thicknet, thinnet and twisted pair do not have a explicit transceiver - dont they require one or it is in the NIC(for thinnet) or hub for twisted pair

A: You are correct, thinnet and twisted pair do not have an external transceiver. The necessary transmission hardware is part of the network interface card (NIC) for thinnet. In twisted pair Ethernet, the hub contains active electronics that can amplify and retransmit signals. Thus, the NIC in a given computer only needs to propagate the signal as far as the hub.

Q: Why is 10Base-T called so

A: The "10" stands for the transfer rate of 10 megabits per second. The "T" stands for twisted pair. Thicknet, which has a maximum cable segment length of 500 meters, is named 10Base-5, and thinnet, which has a maximum cable length of 200 meters is named 10Base-2. (Note: the names can be written without the dash).

Q: In Twisted pair - we refer to the logical topology as a BUS but the physical topology is Star - have I got it right.

A: Yes. The original Ethernet was, of course, both a physical and logical bus -- a single cable comprised the medium over which signals were transmitted. From the point of view of an attached computer, twisted pair Ethernet appears logically to be exactly the same as a single cable (i.e., twisted pair Ethernet uses CSMA/CD for media access just like the original Ethernet). Physically, however, twisted pair Ethernet consists of a hub to which each computer connects, making it a physical star. One often hears the terms "star-shaped bus" or "bus-in-a-box" used to describe the configuration.

Q: Why is that the hosts on the ethernet need to be seperated by a minimum distance (3m?). I understand the need for maximum distance.

A: This answer from Tim Korb:

It's in 7.6.2 of the spec. The placement is to reduce signal reflections and, in particular, to make sure that placement does not "add in phase to a significant degree". The spec is not to insure a minimum distance, but to insure regular placement. The placement distance, incidentally, is 2.5 meters.

Q & A on 100BaseT and 10BaseT Cabling,

Q: Can 100-Base-T ethernet cables be used with 10-Base-T cables? In which case, some pairs are just ignored?

A: There are two parts to the answer. First, as long as the cable meets the standard (i.e., category 5), the same type of cable can indeed be used for either. Second, twisted pair Ethernet uses RJ-45 connectors (8-pin modular connectors that are larger versions of 4-wire connectors used on a conventional telephone). As long as all eight wires are connected, the same connector can be plugged into either 10 or 100 Mbps equipment.

As a practical matter, most network interface cards are now called ``10/100 cards'' because the hardware automatically senses whether it has been connected to a 10Base-T hub or a 100Base-T hub. The same cable can be used between the computer and the hub in each case. In our lab, for example, when we ask students to measure 10 and 100 Mbps Ethernet, they switch computers from one to the other merely by changing the hub -- the same cable is used.

Q & A on One LAN or Many LANs on a Campus,

Q: I have a question about LANs. Are computers on a large university campus on one LAN or many LANs?

A: In general one LAN is incapable of supporting an entire large campus. As a general rule, each LAN is limited to an area approximaely the size of a single building. Indeed, mnay large unoversity buildings have more than one LAN. There are exceptions, of course, but you can use that as a guideline.

Q: Is it right that Ips with same mask are on a same LAN?

A: "Ips" is not a valid technical term. I assume you mean IP addresses (the 32-bit value assigned to a host on an internet). If so, the answer is "no". It's not the mask itself that determines whether two computers are on the same network, but whether the prefixes of the two addresses match. The mask simply tells where the prefix ends.. For example, the network in the Xinu lab here at Purdue and the main CS departmental network both use the same mask:

255.255.255.0

However, the prefixes differ in the third octet. Thus, two hosts on those two networks might have addresses:

128.10.2.1

and

128.10.3.1

When the mask is applied (logical and), the resulting prefixes are

128.10.2.0

and

128.10.3.0

which differ. However, the following two addresses are on the same network because when the mask is applied, both addresses have prefix 128.10.2.0

128.10.2.26

and

128.10.2.3

Q & A on ICMP and UDP "ping",

Q: Touching the subject "source for ping" I think that could be useful to cite an article of Eric T. Horne, published by SysAdmin in the July/August 1993 issue, where he shows the source code for a newping that uses the TIME/TCP port, instead of the traditional ICMP, to detect CPU activity for the destination machine. I hope this citation be useful.

A: Actually, one doesn't need to use the time port because both TCP and UDP have a standard port reserved for echo: port 7. A program called ``upds'' has been floating around for many years that uses the UDP echo port exactly like ping uses ICMP echo. In fact, when I lecture to professional audiences, I usually talk about udps and explain that unlike ping, it determines more than whether interrupts are working on the remote computer.

Q & A on Netweork Analyzer Software,

Q: I am planning to use your book, Computer Networks and Internets, for my class (Computer Networks) in the coming Fall semester. As you wrote in the preface that students seem to understand more on the material if they see packets on a real network. You also mention about an inexpensive network analyzer software. Would you please give me the name of the network analyzer software that good but not too expensive? The department cannot afford to by an expensive HP network anlyzer.

A: Here at Purdue, we have used a variety of network analyzer software running on a workstation (i.e., a PC) rather than a dedicated box. Currently, we're using 'snoop' (a program available with Solaris); we used to use 'etherfind'. To make it 'safe' for undergrads, we (1) install an extra NIC in each workstation that connects to an experimental network, and (2) use the sudo program to invoke snoop, which restricts what the students are allowed to do.

I should tell you that, it's not difficult to roll your own -- as a first project in my graduate-level internetworking course, I have each student build an analyzer (put the interface card in promiscuous mode and selectively dump packets).

Q: I totally agree with you that teaching computer network, the lab is a must. Your book is very good, you make something so complex to be simple.

A: Thanks.

Q: I will teach this course for one-semester, what Parts should I cover? Part 1 through 3 as you suggested in the preface?

A: I'm currently teaching a senior-level networking course from the text, with the following empahsis:

  • 1.5 weeks : Introduction, signals, media, bandwidth, throughput, snd multiplexing

  • 5.0 weeks: Packet transmission concepts and technologies; LANs, WANs, and local loop technologies

  • 5.0 weeks: Internetworking fundamentals and internals
  • 3.0 weeks: Internet applications

Q & A on Writing a Network Analyzer,

Q: I'm interested in exploring the idea of writing one's own analyzer. What do you use for this, the Berkeley packet library?

A: The grad students use my operating system, Xinu. We give them a device driver that can put the NIC in promiscuous mode to receive packets; they build the rest inside the kernel. Undergrads use snoop to capture frames, put them in a file, and then decode them offline (there are packet traces on the CD-ROM that comes with the book if you want to try decoding headers but don't have direct access to the driver).

Q: Also, I've just recently become more interested in networking, and I'm pretty much teaching myself this stuff. I was wondering what kind of approach you'd recommend for this type of education. I've read your TCP/IP Volumes I and III, as well as the RFCs for TCP,IP,ICMP. It's a bit of a curve, but once you read a few you want to read them all. I enjoy just reading the specs. What I guess I really need is a big project.

A: Yes, the only way to really appreciate the subtleties is to build. You can do packet analysis to find out about header details of existing protocols or watch traffic, but I suggest trying to implement a reliable protocol. If you don't have low-level facilities available, start with UDP -- build your own protocol and use UDP as a 'delivery' mechanism. Then, place an intermediate application between the two sides that delays, reorders, duplicates, or purposefully damages a few bits. See if you can design a protocol that detects/corrects the problem.

Q & A on Interpreting IP Addresses in Octal,

Q: Recently, I got a IP address for my computer in one of my university's resident halls. The address is read as xxx.xxx.xxx.070. So I did a ping to this address (just want to make sure it's not used by other people since I haven't connected my machine) and found out the machine already exists. When I did a telnet, I was really connected to a machine. By looking more carefully, I found I was connected to xxx.xxx.xxx.56 instead. What is the explanation?

A: Understanding the mystery requires you to know several facts:

1) 56 in decimal is 70 in octal (base 8).

2) The C programming language (and UNIX programs in general) follow the convention of interpreting constants with a leading zero as being an octal number.

3) Many TCP/IP programs such as ping and telnet that accept a dotted decimal address as an argument follow the C conventon.

I suppose that someone who was unaware that software could be confused by leading zeroes chose to represent 70 as 070 when they handed out your address. They probably thought it would make the printed version look nicer...

Q & A on New Top-Level Domains for DNS,

Q: I thought the elaborated domain name set (most significant segment list) shown in Figure 26.1 (p. 367) of the 2nd ed. had not received final approval and therefore was not (yet) in use. Did I miss a post on this and am I mistaken? Please advise as to the status of this.

A: Well... I made a bad call on this one. While I was revising the text last Spring, the new list was being considered. I each a tutorial with Paul Mockapetris (the guy who invented DNS), and he thought adoption had high probability. So, I gambled that it would be in place by now.

But... as far as I can tell, there's been no formal action yet. Furthermore, with the untimely death of Jon Postel, many things are changing, including the imminent creation of the Domain Name Service Organization.

I'll add this item to the errata.

Q & A on WAP and TCP.

Q: I would like to know why is that why WAP doesn't use TCP?

A: WAP (Wireless Access Protocol) isn't a transfer protocol like HTTP. Instead, it's a complete protocol stack. Although WAP doesn't rule out using TCP, the main focus is on handheld devices:

1) WAP is intended to run over existing protocols that have been developed for delivering data across the cellular telephone system (e.g., CDPD).

2) WAP is optimized for delivery channels that have low bandwidth.

If reliability is needed, the Wireless Session Protocol (WSP) component of the WAP stack must provide it.

Q & A on TCP Segment Lengths.

Q: I have a couple of quick questions regarding the TCP protocol.

1. When I checked the TCP segment format, as shown in fig 22.6 of your Computer Networks and Internets book, I did not find any field in the header to indicate the segment length. And the question is: - How does the IP protocol in the same host know the length of the segment?

A: The length is not stored in the header. However, when TCP manufactures a segment, it passes the length (and other information) to IP along with the segment.

Q: - Also, how does the TCP protocol in the other side know the length of the segment?

A: When IP receives a datagram carrying TCP, IP computes the length of the segment (from the IP header length and total datagram length), and then passes the length to TCP along with the segment.

Q: 2. As far as I know, a TCP segment will be sent to IP to transfer it to the other side. The TCP header only has DESTINATION PORT in its header, which is just 16 bits. From where the IP protocol will know the IP address of the destination/source?

A: The IP destination address is among the additional information that TCP must pass to IP along with an outgoing segment.

Q: As far as I know, the application layer knows about the ``connection'' and its two endpoints. However, there is no direct link between the application layer and the IP layer. That is why, I am asking my question.

A: There must be an Application Program Interface (API) that allows the application to specify details such as the IP address and protocol port number of a remote site. Once the information has been specified, protocol software has access to it.

Q & A on TCP/IP Between Hosts on a Single Network.

Q: I just wanted to know if TCP/IP is required when the client and the server are located on the same physical network.

A: If the operating systems on the two computer provide support for some other suite (or direct access to the underlying network), TCP/IP is not required. In practice, however, chances of being able to use an alternative are extremely slim -- no protocols are available on as many computer systems as TCP/IP, which has become the universal language of networking.

Q & A on "Internetworking with TCP/IP, Volume 1".

Q: What is the title of this book (Volume 1 of Internetworking with TCP/IP)?

A: The book to which I referred is:

 D. Comer,  Internetworking With TCP/IP Volume 1: Principles,
Protocols, and Architectures, 3rd edition, Prentice Hall, 1995.
ISBN 0-13-216987-8

You can find a list of all my books on my Web page:

 http://www.cs.purdue.edu/people/comer

Q & A on TPC/IP Layering Model,

Q: why does the book, at pp. 230, show that the TCP/IP has 5 layers, while other books (e.g., Tanenbaum's and Hunt's books) say it is 4 layers? Is it network interface layer and physical layer?, or is it host-to-network layer?

A: When I wrote Volume 1 of Internetworking with TCP/IP, I was on the IAB working with the researchers who created the protocols. I documented what they had created: a 5-layer model. Furthermore, I used the names we commonly used for the layers (e.g., network interface layer). Since then, other authors have tried to rephrase the model (e.g., at least one author omits the hardware layer). I suppose they hope such changes will increase sales of their books.

Q & A on IP Address Prefixes and Suffixes

Q: Our class had a question about table 16.13 on page 245 (2nd edition).

The headers in the table are "prefix" and "suffix", implying that these address the bits AFTER the bits identifying the address class.

A: When I use the term ``prefix'', I include the bits that identify the class as well as bits that identify network.

Q: We had a question about the entries for "this computer" and "limited broadcast". Is this really referring to the prefix (where self-identifying bits for address class are still used), or are all octets in the address 0's or 1's.

A: The address labeled ``this computer'' consists of all 32 zero bits, and the address for ``limited broadcast'' consists of all 32 one bits. The class bits are not interpreted in these special addresses.

Q & A on "Net 0" IP Addresses.

Q: Is it Ok to assign 0.xx.xx.xx to an IP host number, where xx != 0, i.e., class A with a prefix = all-0s and suffix is any thing, but not all-0's.

A: The question doesn't need an asnwer: addresses on the Internet are assigned by a central authority, so the question is irrelevant. Addresses on private networks are assigned to avoid global addresses (e.g., the IETF recommends using the class A address 10.0.0.0, which will never again be assigned to any network in the Internet). Thus, one would never assign 0.x.x.x in either case.

Q: But according to Tanenbaum, pp. 417, he said that when a prefix is all-0s and suffix is HOST, it means a host on this network. He added, these addresses allow machines to refer to their own network without knowing its number, but they have to know its class to know how many 0s to include.

A: That doesn't make sense. One cannot know the ``class'' of the local network address without knowing the address.

Q: This means, according to Tanenbaum, that 0.xx.xx.xx is a special address. However, I did not find it listed as a special address in Figure 16.7. That is why I got confused about this address.

A: There's no point in worrying about it because it's not used that way in practice.

Q: With reference to:

Is it Ok to assign 0.xx.xx.xx to an IP host number, where xx != 0, i.e., class A with a prefix = all-0s and suffix is any thing, but not all-0's.

Would it be a simple case of xx != 0? (Even with an ordinary class A prefix: 40.0.0.8) Obviously not all zeros, but some zeros are permitted.

A: I understood the question to be whether it was permissible to use the Class A prefix that consists of eight zero bits. At least some of the host part (the last three octets) will be nonzero, but that doesn't answer the question of whether Class A prefixes start at 0 or 1.

Q & A on Network Standard Byte Order and User Data.

Q: I can understand the neccessary of the internet standard for byte order. But, why the user data field in packet is exempt from the standard?

If i communicate between a Little Endian machine and a Big Endian machine, the data would be misunderstand or my program must deal with the byte order, which means that my program is related to the unique machine, right?

A: You are correct in asserting that all data must be translated. If an application running on a Little Endian computer merely transfers a copy of the bits of an integer to an application running on a Big endian computer, the receiver will interpret the value of the bits differently, resulting in an error.

However, it does not make sense for network protocol to require translations because only the application programmer understands the data being sent across the network. If an application uses non-numeric data or has a reason to specify a particular representation, the network protocols should not interfere.

As a result, application programmers have complete freedom to choose a data representation, but also have the responsibility to handle any byte-order conversions or their clients and servers will not work correctly when communicating between two computers that have different native byte orders.

Q & A on Network Topologies,

Q: 1) Can a ring topology be used on Ethernet? If yes, how?

A: No, Ethernet uses a bus topology.

Q: 2) Would a pure ring or a star ring topology be easier to maintain and troubleshoot? Why?

A: Is this a homework problem?

Q: 3) What is the maximum distance (in meters and feet) a node can be from a hub without any repeaters in between?

The nominal length of a twisted pair segment is 100 meters; slightly longer wiring *may* work, depending on the amount of electrical noise in the environment and the exact type of cable.

Q & A on Code for Internetworking with TCP/IP, Volume 3

Q: In your book, (sorry forget the title -Networking with TCP/IP?) Volume III, is the example code for client and server available on the Internet for download?

A: All the code from my books is available for download. Volume 3 comes in three versions that use slightly different interfaces: Sockets, TLI, and Windows sockets. The easiest way to obtain the code is from the following Web page which has a link to the code for each networking book:

Archives