On Monday, July 14, 2003, at 5:28 PM, Daniel Frimerman wrote:
Thank you very much Guy and Ian. I understood everything you said.
So...nor my OS (windows) or the remote system have knowledge about speed
limits on the ethernet devices?
Your OS presumably knows that your Ethernet device is a 10Mb/s device; however, it's not going to throttle senders to 10Mb/s, except perhaps by returning an error if you're sending packets so fast that you exhaust all the buffering allowed for an application sending raw packets.
Your OS does not, however, know that the Ethernet device in question is connected by, for example, a point-to-point Ethernet cable to a cable modem with an upstream speed of 128Kb/s.
I'm not sure what "remote system" you're referring to, so I can't answer the question, except to say that if the remote system isn't your cable modem, then the remote system probably doesn't even know you *have* an Ethernet, much less that it's a 10Mb/s Ethernet.
So, even for Windows, to send data correctly (since it knows nothing about
my cable modem) it has to use TCP.
Correct.
Other protocols have no reliability at all - unless they use tcp-like protocol?
Correct. Ethernet is *not* a link-layer protocol that guarantees reliability, so anything that runs atop Ethernet has to provide its own mechanism to provide reliable delivery of data.
So packets like ARP will be sent twice if no reply has been recevied after a
certain period?
ARP implementations might re-send a request if they don't get a reply after a certain period; if so, they'll probably give up eventually and return an error if they don't get a reply after multiple retries.
I have this case scenario... Say, I send UDP packets at 10mbit.
I.e., you send UDP packets on a path where the first hop causes them to be transmitted on a 10Mb/s link.
The remote system is 100mbit and able to
send me replies in <50ms time. Say, my cable is limited at 128kbits. So, I
will reach my limit pretty quick. Does this mean that I will have to send a
certain amount of data twice since it was dropped by the cable system?
That depends on whether any flow control is done at a higher layer. If not, then if acknowledgement is done at a higher layer (so that you know that the packet was dropped, because the remote machine didn't acknowledge it), you will, indeed, have to send some data twice.
If you need reliable delivery, you might well want flow control as well, so that, instead of sending packets too fast and retransmitting them, which can clog the network, you limit the rate at which you send packets. A receiver using a protocol providing flow control will advertise a "window" to the sender, specifying a certain number of packets, or bytes, that it's willing to accept. (TCP uses bytes; at least some other protocols use packets.) The sender keeps track of how much it sends to the receiver, and will not transmit any more data than the receiver has said it's willing to accept. If it transmits data to the server, it subtracts that (bytes, or packets) from the last window size offered by the receiver. If the window is too small to send data, it won't send any data until the receiver tells it that the window has "opened up".
This will limit the flow of data so that the receiver won't have to throw data away because it doesn't have enough room to buffer it; however, it doesn't take into account the capacity of the entire network between the sender and receiver, which could include slower links whose speed the sender doesn't know (and even the receiver might not know it), or routers or switches with a limited amount of buffering. See, for example, the classic
http://ftp.ee.lbl.gov/papers/congavoid.pdf
and
http://www.psc.edu/networking/tcp_friendly.html
for some discussion of congestion control; as the message at
http://www.kohala.com/start/vanj.88feb11.txt
(which discusses much of the same stuff as the paper at the first of those two URLs) says:
(Without slow-start, by contrast, when 10Mb ethernet hosts talk over the 56Kb Arpanet via IP gateways, the gateways see a window's worth of packets (8-16)
delivered at 200 times the path bandwidth.)
which is a problem similar to the one you're seeing (only you have a little more than twice as much bandwidth on your upstream path as the 56Kb Arpanet links did; you also have a lot more downstream bandwidth, but that's another matter, and I think there are other issues that this asymmetry introduces).
Is that how windows operates?
Windows, as a whole, doesn't operate in any single fashion here.
Its TCP implementation does, as far as I know, all the polite "Van Jacobson" (the slow-start, etc. stuff discussed in the first and third of the documents cited above; he's the "vanj" in the 3rd URL) stuff that TCP implementations are supposed to do, and thus does its part to limit the rate at which it injects packets into the network (which can't necessarily be done based on the speed of its link to the network, as has been seen here - you're really limited to no more than 128Kb/s, even though you're on a 10Mb/s network, and other devices on the network might, for whatever reason, limit you even more).
Its UDP implementation lets clients do whatever they want; it's up to the application using UDP to do the right thing. I don't know whether, for example, Windows Media Server does that for UDP-based protocols, or if it just floods the network (although you are probably not going to be playing a lot of WMS streams from behind your cable modem).
Its ARP implementation probably retransmits some number of times if it doesn't get a reply.
================================================================== This is the WinPcap users list. It is archived at http://www.mail-archive.com/[EMAIL PROTECTED]/
To unsubscribe use mailto: [EMAIL PROTECTED]
==================================================================
