Van Jacobson (firstname.lastname@example.org)
Mon, 08 Dec 86 10:44:47 PST
ack and is essentially unrelated to when a segment is originally
ent (The code wasn't intended to work this way and on low delay
circuits it works correctly.) We should really be retransmitting
B 2*R from its first transmission (i.e., 1 line after the 2R tick
mark). It's not too hard to show analytically that this (the
current 4.3 algorithm) "feeds forward" (e.g., the recovery for D
is moved later in time and is more likely to conflict with F,G
recovery) which is why throughput degrades much faster than
linearly with increasing loss rate.
You can view the late transmission of D two ways. It could be
another example of the timer problem. I.e., we should have
retransmitted D 3 lines after the 2R tick. We held off sending
it then because we thought the network might be congested and we
wanted to send a minimum amount of data until we got back an
indication (the ack) that the congestion had cleared up. But we
certainly should have sent D at 4R when we got the "c" ack.
Or you can say that when we get the "c" ack after the
retransmission of B, no packets have been injected into the
network for 2*R. The ack tells you pretty clearly that the
receiver is missing D. (Either point of view will do the "right"
thing in this case but treating a retransmit ack specially buys
you a bit in one other case).
If the two problems are corrected, the total time drops from 7R
to 4R (2R is the total time if no packets are lost). If we don't
do the send-1-packet-on-rexmit congestion control, the total time
drops to 3R, the mimimum possible if one or more packets is
Also, this partly illustrates why I thought Craig's measurements
demonstrated a problem in TCP rather than the superiority of RDP.
Even with EACKs, it takes RDP 3R to send the data if the same two
packets are lost, exactly the same time it takes TCP. I think I
can show that EACKs aren't a big win until the drop rate is >50%,
if TCP is working as well as it can (that's not to say RDP isn't
a win for other reasons).
This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:37:00 GMT