[lkml]   [1996]   [Aug]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Networking stalls: More details
>>>>> "Olaf" == Olaf Titz <> writes:

Olaf> Pedro Roque Marques <> 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.


 \ /
  Last update: 2005-03-22 13:37    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean