Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8209840

More effective record delivery

    Details

    • Type: Enhancement
    • Status: Open
    • Priority: P3
    • Resolution: Unresolved
    • Affects Version/s: 11
    • Fix Version/s: tbd
    • Component/s: security-libs
    • Labels:
    • Subcomponent:
    • Introduced In Build:
      b20
    • Introduced In Version:
      11

      Description

      Reported in OpenJDK:

      > > On 7/12/2018 1:17 PM, Simone Bordet wrote:
      > > Currently:
      > > - Server wraps 160, 6 and 907 in 3 wraps.
      > > - Server *sends* the 1073 bytes in 1 TCP write
      > > - Client unwraps 160, then goes into NEED_WRAP
      > > - Client wraps 6, then goes again into NEED_UNWRAP to finish with the
      > > 6 and 907 received by the server.
      > >
      > > What I'm suggesting:
      > > - Server wraps 160, 6 and 907 in 3 wraps.
      > > - Server *sends* the 1073 (160+6+907) bytes in 1 TCP write
      > > - Client unwraps 160, stays in NEED_UNWRAP, unwraps the 6, unwraps the
      > > 907, then goes into NEED_WRAP
      > > - Client wraps 6 and 58
      > > - Client *sends* the 64 (6+58) bytes in 1 TCP write.
      > >
      > > The 6 bytes of the dummy change_cipher_spec are *sent* just after
      > > receiving the ServerHello in both cases, they are just *generated* at
      > > different times.
      > >
      > > By having all the unwraps() consecutive and all the wraps()
      > > consecutive you can enable a number of optimizations I described
      > > earlier.
      > >
      > > Imagine a client that would perform a TCP *send* every time the state
      > > moves away from NEED_WRAP.
      > > Currently it would:
      > > 1. TCP send for ClientHello
      > > 2. Reads 1073 from server
      > > 3. Unwrap 160, then NEED_WRAP
      > > 4. Generate 6, then NEED_UNWRAP
      > > 5. TCP send the 6 bytes
      > > 6. Unwrap 6 and 907, then NEED_WRAP
      > > 7. Generate 58 then FINISHED
      > > 8 TCP send the 58 bytes.
      > >
      > > You can see that the client issues 3 TCP sends.
      > >
      > > With what I am suggesting, the client would only issue 2 TCP sends,
      > > which seems more in line with the efforts in TLS 1.3 to be more
      > > efficient.
      > >
      > > It would just be a matter of *generating* those 6 bytes a bit later,
      > > *after* having fully unwrapped the ServerHello.
      > >
      > On Fri, Jul 13, 2018 at 3:45 PM Xuelei Fan <xuelei.fan at oracle.com> wrote:
      > It's a good idea!

      I just built:

      $ hg id -i
      76072a077ee1

      and I can still see the (very) inefficient behavior above.
      Are there plans to fix it?

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                xuelei Xue-Lei Fan
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated: