Messages in this thread |  | | Date | Mon, 19 Aug 1996 22:38:28 +0100 | From | Pedro Roque Marques <> | Subject | Re: Networking stalls: More details |
| |
>>>>> "Olaf" == Olaf Titz <olaf@bigred.inka.de> writes:
Olaf> Pedro Roque Marques <roque@di.fc.ul.pt> wrote: >> For these cases the *link* protocol should provide >> retransmition. Most links do already provide such >> features... HDLC based LL protocols, which i believe are still >> the most common on leased lines, check and retransmit lost >> frames.
Olaf> Which can lead to "nice" interference with TCP Olaf> retransmissions.
Since we disagree it with be better to base the discussion on observable facts. I point to the defense of my argumentation the fact that the Internet has been running for 15 years using TCP/IP, predominantly on top of HDLC based links and no "nice" interference has been noted.
Olaf> At the very least, it spoils the RTT estimator.
How ? What is the difference between a link retransmit and delay in a interface sending queue ?
Olaf> At worst, it retransmits slower than the TCP layer.
Are you stating that a restranmit on a hop is slower that a restransmit on a full path ? I cannot conceive this. FYI the estimated diameter of the internet is around 30 hops, slightly more.
Do you know how does TCP detect segment failure ? A retransmit is done when <smothed_rtt + 4 * medium_deviation> as elapsed since the packet was sent or when 3 consecutive acks show that the segment is missing.
On the first case a retransmit completly stalls the pipe.
You are definitively wrong here.
Olaf> I'm skeptical if stacking retransmitting protocols is Olaf> capable of doing more good than harm at all...
Well, it has been done for ages on point-to-point links... in fact TCP was designed at a time where maybe all point-to-point links used HDLC or some variant.
But i still note that, in my experience, most PPP connections have a small packet loss rate. Links should present a packet loss rate bellow 1% for TCP to function properlly.
And i repeat again that for TCP, segment loss represents congestion, always. You might be able to create a protocol where this would be no longer true but then it would stop being TCP. However i'm curious about what other solutions exist to detect congestion which is *the* problem on large scale networks. Backward congestion notifications by routers never really behaved well since they have the tendency to agravate the problem. Besides, we're the end to end community.
regards, ./Pedro.
|  |