[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    [W:0.019 / U:3.988 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site