Learning about Networking - Questions... 1

[Accessdabbler]

I'm learning about networking and I have some questions about packets (or frames).

Question 1: If Computer A needs to send multiple packets to Computer B, is there a "buffer" that holds assembled frames before they get sent down the network?

Question 2: If Computer A needs to send a large number of frames what is the time delay between sending frames? Since Computer A is not allowed to monopolize the network there must be some built-in mechanism to force Computer A to wait some small amount of time before checking the network cable to see if it is free. Otherwise, Computer A would keep sending frame after frame.

Question 3: In a token ring network, in simple terms, what keeps the token from moving in the opposite direction around the ring? In theory, applying voltage to a line causes the pulse to transmit in both directions down the wire, wouldn't it?

Thanks for your assistance.

 

[svermill]

1. Yes. It varies by protocol exactly how. When a TCP connection is established, buffer space is reserved. The amount of space reserved dictates, to a large degree, the window size. Also, there are generic interface buffers.

2. As far as I know, on a shared segment, a machine can in fact dominate.

3. A token ring is only logically a ring. It is physically a star with a tx and rx pair going out from the central MAU to the machines.

 

[jimbopalmer]

1) ethernet needs at least a 1.5k hardware buffer to hold a packet, when RAM was expensive, 8k was common, now I rarely see less than 64k, in unix there is a software buffer before the card, I usually alter it to 64k as well.

#!/bin/sh
# Set the TCP hiwater marks to 64K to improve SunSwift SBus
# Adapter performace. JJP 22-Aug-2000
case "$1" in
'start')
echo "Setting local kernel parameters...\c"
ndd -set /dev/tcp tcp_xmit_hiwat 65535
ndd -set /dev/tcp tcp_recv_hiwat 65535
ndd -set /dev/tcp tcp_cwnd_max 65534
echo ""
;;
'stop')
echo "No kernel parameters changed."
;;

*)
echo "Usage:$0 {start|stop}"
;;
esac
exit 0

2) when a collision occurs, two devices tried to transmit at once, both wait a random time to retransmit, and yes some cards cheat and wait much less than other cards, gaining an advantage on a shared network. with switches, this is much less an issue. The switches I use have 4 meg buffers for packets to wait their turn in. I tried to remain child-like, all I acheived was childish.

 

[Accessdabbler]

1) Where is the buffer? In RAM, on the HDD or on the network card? Though, I don't remember seeing memory specs on network cards....

2) I don't agree about one machine dominating. I understand how collisions are resolved but, I hope you can see my point, there MUST be some delay between sending frames or the sending system would never get acknowlegdements or other frames from the receiving system to slow down the sender. My thinking is that the sending system sends a frame, listens on the network for a period of time, then, checks to see if the line is busy and, if not, sends the next frame.

3) I understand the difference between logical and physical setup but in Token Ring, each packet sent on the network can't be sent to every NIC (like in Ethernet) or every NIC will think they are receiving the token (unless, a data packet is sent without the token, I'll have to review my notes...).

 

[jimbopalmer]

1) on the card, here is an old pdf of a 4.8k RAM 10 meg ethernet card

http://www.smsc.com/main/tools/discontinued/91c94.pdf

Here is a 1 gig ethernet card with 1 meg of RAM

http://www.syskonnect.de/syskonnect/products/b0101_ethernet_9821.html

this article on 10g ethernet hints it may need a gig of RAM per card

http://www.nwfusion.com/news/2001/1029infra.html

I tried to remain child-like, all I acheived was childish.

 

[svermill]

1) Don't know all the details and it probably varies widely. Too far outside of my area of expertise.

2) Don't see much shared ethernet anymore so I need to be careful with my assumptions about your question. In any ethernet topology, there is a small "inter-frame gap" between frames. This has to do with letting receivers do a little housekeeping between frames I think. I believe that the gap is shorter than what would be required for another transmitter to seize the segment, but I won't swear by it. I'll try to find out.

In a shared ethernet environment, using tcp as an example, a transmitter’s window will eventually collapse and it will have to stop and wait for acks. Another transmitter could easily sneak in and take the segment. However, this has nothing to do with ethernet. Ethernet does not wait for acks. It's a connectionless technology. If it were UDP (also connectionless) at layer 4 instead of TCP (connection-oriented), the ethernet NIC would just keep on dumping onto the network whatever UDP dumped on it (at least it will do that as long as it can maintain acceess to the resource).

3) Remember that in token ring, every station passes any frame put onto the ring. If the traffic is clockwise (and I think it is), and station D were immediately counterclockwise of station A, stations B and C would receive and then re-transmit the frame on behalf of A. Furthermore, station D would pass it clockwise to station A so that station A would know that everything went as planned. Every frame makes a complete circle around the entire ring. Once that happens, the token gets put back on to the ring so that someone else can seize it.

 

[svermill]

follow up to 2)...

It would appear that any station that has waited for the interframe gap to expire can make an attempt at transmission. This seems silly to me since several stations could easily have data queued, have waited for interframe gap to expire, and then all transmit at once. Boom - collision Then the backoff algorithm takes place and it's more likely that only one station will attempt to transmit.

Interesting, there is a Gig-E extension that allows for bursting. The transmitter keeps an idle pattern on the line during interframe gap. In this way, all others still sense carrier and don't contend for access. This is allowed to happen for up to some max burst size.

By the way, to answer your original question, the interframe gap is 96 bit times.

And one final note: there are two camps where interframe gap is concerned. About half the sources I read (including the actual IEEE spec) stated that interframe gap was 96 bit times to allow receivers and the actual physical media to "settle." The other half stated that it was necessary to allow a NIC to transition from tx'ing to rx'ing in the case of some type of response (TCP ack in an ethernet frame, for example). None stated that the purpose of the gap was to allow for fair access. But since any transmitter is free to contend, it seems to have that affect.

Cheers.

 

[jimbopalmer]

Unix 'sees' the size of the other computers receive window and sizes the send window the same size, so it does not over send data.

TCP
Local Address Remote Address Swind Send-Q Rwind Recv-Q State
-------------------- -------------------- ----- ------ ----- ------ -------

peapod.9249 tridentgum.17255 24840 0 64860 0 ESTABLISHED
peapod.43123 alpha2.6000 64240 0 64240 0 ESTABLISHED
localhost.19693 localhost.9249 57344 0 57344 0 ESTABLISHED
peapod.8588 tacomawa.18488 17484 0 64240 0 ESTABLISHED
peapod.8588 mammothca.13703 17256 0 64240 0 ESTABLISHED
peapod.8588 stocktonca.20633 8420 0 64240 0 ESTABLISHED
peapod.9249 ussendeavour.28444 17520 0 64240 0 LAST_ACK
peapod.9249 wiper.21222 28732 0 64240 0 ESTABLISHED I tried to remain child-like, all I acheived was childish.