Re: General question about TCP and buffering in switch/router/modem
- From: "Thrill5" <nospam@xxxxxxxxxxxxx>
- Date: Sun, 1 Feb 2009 18:05:24 -0500
"JF Mezei" <jfmezei.spamnot@xxxxxxxxxxxxx> wrote in message
news:0071e8de$0$10051$c3e8da3@xxxxxxxxxxxxxxxxxxxx
I have the following setup:
COMPUTERS ROUTER MODEM1 MODEM2
| | | | |
============ =========================
VLAN 10 [Switch] VLAN 20
ROUTER has a fixed 10mbps/half duplex interface for its wan port.
MODEM1 has a fixed 10mbs/half (acts as backup)
MODEM2 has auto adjust 10/100 half/full duplex.
ADSL service is 5mbps/800kbps.
The switch negotiates properly with each device.
QUESTION:
Say the window size is 64k (roughly 50 packets). When the computer
starts sending data after the TCP call has been established, is it
correct to state that it will send a burst of 50 packets at 100mbps
non-stop to fill the window and only after that will it moderate its
sending throughput to match received ACKs ?
No it is not. TCP only increases the TCP window by 1 packet each time an
ACK is received and the receiver's TCP buffer is not full. Each time a
packet is dropped, the TCP window is cut in half. This is a gross
simplification of initial TCP window size, but adequate to answer your
question.
If the router's buffers are not large enough, it will be dropping
packets from the initial burst of 50 packets, right ?
Similarly, the modem will be receiving data over 10 times faster than it
can push it onto the ADSL line, so the modem would also be losing plenty
of packets in that initial burst.
It is normal/expected that the first batch of packets in a TCP
connection will experience high packet loss rate ? Or is there
expectation that the devices allong the way should be able to buffer the
full window size ?
It is NEVER expected that any device (router) between the sender and
receiver will buffer ANY traffic. Buffers in routers are there because
traffic is inherently bursty, and buffers allow traffic to be queued for a
very small period of time, instead of dropping it. "small" is relative
depending on the speed of the interface. On a 56K line, small might be
500ms, but on a 100MB/s interface small might be on only 1ms or 100us.
Buffering is NEVER substitute for bandwidth, and buffering data causes
jitter.
You need to read up on TCP. An explanation here would take too long for me
While I am at it: is there a standard time/logic that a sender uses to
waits for an ack before starting to resend data from the last aked
sequence number ?
to write.
In terms of the switch:
Since the router's WAN port is fixed at 10/half and it talks to the modem.
Are there any advantages/disadvantages of having the modem at 100/full
vs 10/half in terms of performance ?
No, but always use 10/full whenever possible because 10/half has an
effective maximum bandwidth of about 3Mb/s in each direction. 10/full has
an effective maximum bandwidth of about 9 Mb/s. If both connections are
10/half you could possibly have two bottlenecks and more dropped packets
meaning lower performance.
aka:
10/h <----> 10/h
100/f <----> 10/h
My thinking is that by having the modem at full duplex, it would remove
some latency and would let the switch worry about feeding the older
router at the right time/rate.
Latency is not the problem, because at 10Mb/s each hop adds about 52us
(thats micro seconds, millionths of a second, not milli seconds, or
thousandths of a second). As a comparison, a 5MB/s ADSL line adds at least
3 or 4 ms in delay, or 3000 or 4000 us (because of speed (aka serialization
delay) and the distance the signal must travel.) Everything is relative, so
adding a few microseconds in delay is a drop in the bucket compared to the
RTT of your slowest link.
.
- Follow-Ups:
- References:
- Prev by Date: Re: CISCO Supervisor question
- Next by Date: Re: NAT-T is supported by cisco 831?
- Previous by thread: General question about TCP and buffering in switch/router/modem
- Next by thread: Re: General question about TCP and buffering in switch/router/modem
- Index(es):
Relevant Pages
|
