<html>

  <head>

    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">

  </head>

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

    <div class="moz-cite-prefix">On 5/19/2018 6:51 AM, Michael Wojcik

      wrote:<br>

    </div>

    <blockquote type="cite"

cite="mid:SN1PR18MB2112A9B914F9C2254DD726B0F9970@SN1PR18MB2112.namprd18.prod.outlook.com">Right.

      And TCP is an ordered byte-stream protocol. That means to receive

      a control message from the peer, the local stack *must* have

      received everything transmitted prior to it. (Modulo SACK, but

      SACK'd data preceeded by a gap is invisible to the application, so

      we should ignore it.)</blockquote>

    <br>

    And yet TCP itself moves ACKs when there's no window available.<br>

    <br>

    TLS could (but as far as I can tell does not) have such a

    mechanism.  It could have a window, like TCP, where the receiver

    would say "you can send me 64K of data", and the sender wouldn't be

    allowed to send data (but could send control messages) when that

    window is exhausted, until the receiver reopens the window.  It

    could have control messages like XON and XOFF that say "please stop

    sending me data (but control is OK)" and "resume sending data".<br>

    <p>Each scheme has its problems (mostly around how much data can be

      in flight at any one time), but they're both clearly possible.</p>

    <p>It does seem like some sort of flow control would be desirable,

      so that the receiver doesn't have to have some way to handle

      arbitrarily large amounts of data to keep the connection healthy.</p>

    <p>Maybe in TLS 1.4.<br>

    </p>

    <pre class="moz-signature" cols="72">-- 

Jordan Brown, Oracle Solaris</pre>

  </body>

</html>