
<html>

  <head>

    <meta content="text/html; charset=windows-1252"

      http-equiv="Content-Type">

  </head>

  <body bgcolor="#FFFFFF" text="#000000">

    <div class="moz-cite-prefix">Am 01.09.2014 um 14:30 schrieb John

      Day:<br>

    </div>

    <blockquote cite="mid:a062408b8d02a15237f38@%5B10.0.1.3%5D"

      type="cite">

      <meta http-equiv="Context-Type" content="text/html;

        charset=iso-8859-1">

      <title>Re: [ih] why did CC happen at

        all?</title>

      <div>Wasn't at least one of the lock up problems that ARPANET

        Messages

        could be up to 8 packets, and the IMP would reassemble a full

        Message

        before delivering it to the host.  Hence, it was possible to get

        many partially reassembled messages in the destination IMP

        without

        enough memory to finish any of them.  Since the IMP wouldn't

        discard anything, it froze.</div>

    </blockquote>

    <br>

    But isn't this an implementation error? In a properly implemented

    flow control, a receiving node must not accept data for parts of a

    packet as long as he doesn't have the memory to reassemble the whole

    packet. <br>

    <blockquote cite="mid:a062408b8d02a15237f38@%5B10.0.1.3%5D"

      type="cite">

      <div><br>

      </div>

      <div>RFNMs made it pretty difficult to over load the IMPs with

        just

        packet traffic, right?</div>

      <div><br>

      </div>

      <div>For what it's worth, many years ago Phil Enslow told me he

        had

        reviewed the proposed ARPANET design (before my time) and had

        said it

        would lock up, but no one believed him.  That is all I know

        about

        that.</div>

      <br>

    </blockquote>

    <br>

    dead locks in reassembly / flow control are a serious concern and

    must be carefully considered in the protocol design.<br>

    <br>

    Actually, this problem is the very reason for the cumulative ACK

    mechanism in TCP: The sender is made ALWAYS to fill up the

    receiver's window from the very left to the right by signalling

    exactly this sequence number to the sender. Otherwise, the

    receiver's buffer might be fully occupied with data - while there is

    a gap in the data flow as delivered to the application and the next

    part residing in the buffer - and no space to fill in the missing

    pieces.<br>

    <br>

  </body>

</html>