lkml.org 
[lkml]   [1996]   [Aug]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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.

\
 
 \ /
  Last update: 2005-03-22 13:37    [from the cache]
©2003-2011 Jasper Spaans