I Appreciate your response
On Tue, Jun 20, 2017 at 2:09 AM, Matt Caswell <matt@xxxxxxxxxxx> wrote:
On 19/06/17 19:11, Neetish Pathak wrote:
> 2) Can you suggest some places to put a time stamp in OpenSSL code.
I agree with Ben's responses to all your other questions. For this
question, I'm not sure what you are trying to achieve? Starting before
SSL_accept/SSL_connect and finishing after they return should be fine.
Or are you looking for a breakdown of where the time is going?
Thanks Matt. I was asking for a breakdown since I was not sure if the SSL_accept and SSL_connect just do the handshake or if they are doing some other things that may impact latency and CPU usage. Just wanted to be clear that calling SSL_connect starts ClientHello , SSL_accept unblocks on receiving ClientHello and sends ServerHello, and both functions return after sending Finished message from their sides (i.e. client and server).
Matt
>
> Thanks
> Best Regards,
> Neetish
>
> On Mon, Jun 19, 2017 at 5:49 AM, Matt Caswell <matt@xxxxxxxxxxx
> <mailto:matt@xxxxxxxxxxx>> wrote:
>
>
>
> On 16/06/17 23:51, Neetish Pathak wrote:
> > Thanks Matt, Appreciate ur response and tips
> >
> > On Fri, Jun 16, 2017 at 3:36 PM, Matt Caswell <matt@xxxxxxxxxxx <mailto:matt@xxxxxxxxxxx>
> <https://mta.openssl.org/> > <mailto:matt@xxxxxxxxxxx <mailto:matt@xxxxxxxxxxx>>> wrote:
> >
> >
> >
> > On 16/06/17 20:08, Benjamin Kaduk via openssl-users wrote:
> > > On 06/16/2017 01:58 PM, Neetish Pathak wrote:
> > >> Hello
> > >> Thanks
> > >> I tried reading some content from the server side and I
> observed the
> > >> new_session_cb getting invoked in that case on the client
> side. I
> > >> understand that may be due to delayed NewSession info
> transfer from
> > >> server side to client side. But it is helpful for saving
> the session
> > >> info on the client side. (Thanks Matt for your input)
> > >>
> > >> However, now I have two concerns
> > >>
> > >> 1) I see that latency for handshake with session resumption in
> > TLS 1.3
> > >> has not improved as much as it improves for TLS 1.2
> > >> With TLS 1.3, I observed that resumption brings down the
> connection
> > >> time from 2.5 ms to 1.2-1.3 ms
> > >> while with TLS 1.2 (using either session IDs or tickets), the
> > >> connection time reduces from 2.5 ms to 0.5-0.6 ms.
> > >>
> > >> The whole code is similar for running the two experiments
> with only
> > >> max TLS version changed. Can someone comment on the latency
> > >> measurements for the two cases.
> > >> TLS 1.3 is supposed to be better than TLS 1.2 in my
> opinion. Please
> > >> comment.
> > >>
> > >
> > > Are you seeing a HelloRetryRequest in the resumption flow?
> That would
> > > add an additional round trip. (Your numbers in milliseconds
> are of
> > > course not transferrable to other systems; round-trips is an
> easier to
> > > understand number.) RFC 5246 and draft-ietf-tls-tls13-20
> both have
> > > message-flow diagrams that show the number of round trips in
> various
> > > handshake flows.
> >
> > Care should also be taken about when you are starting your
> "timer" and
> > when you stop it, e.g. if you stop your timer after the
> session ticket
> > data has been received by the client then this is not a "fair"
> test (the
> > connection is ready for data transfer earlier than the arrival
> of the
> > session ticket).
> >
> > I would expect to see the TLS1.3 latency for a full handshake
> to be
> > around the same as for a TLS1.2 resumption handshake. With a
> TLS1.3
> > resumption only marginally different. There are the same
> number of round
> > trips for a TLS1.3 full handshake as that there are for a
> resumption
> > one. The primary difference is that the Certificate message is
> not sent
> > (which can be quite a large message).
> >
> > Your timings suggest you are testing this over a LAN where the
> effects
> > of network latency are going to be relatively low. The real
> benefits
> > from fewer round trips will really be seen when network
> latency is more
> > significant.
> >
> >
> >
> > In my application program, I put start and stop timer before and after
> > SSL_accept on server side and before and after SSL_connect on the
> client
> > side.
>
> That should be fine (my worry was that you might also be including the
> subsequent session ticket transfer).
>
> > I am not sure how I can put timers at individual steps of Handshake
> > using my client applications. I was assuming SSL and SSL_accept take
> > care of the entire handshake process.
> >
> > Yes, I am testing on local machine. I will migrate my test to remote
> > machines. But I am not really able to understand why TLS 1.3 is slower
> > on my machine.
>
> If you are on a local machine I would not expect a significant speed up
> in TLSv1.3 vs TLSv1.2. TLSv1.3 has been designed to reduce the number of
> round-trips required in order to avoid unnecessary network latency. If
> you are on a local machine then there isn't any significant network
> latency anyway - so timings are presumably dominated by the CPU
> intensive tasks. You should make sure that you are comparing like with
> like, i.e. the same ciphers, key lengths, key exchange algorithms,
> curves etc between TLSv1.2 and TLSv1.3. Differences in any one of these
> could obviously have significant performance impacts.
>
> Matt
>
> --
> openssl-users mailing list
> To unsubscribe:
> https://mta.openssl.org/mailman/listinfo/openssl-users
mailman/listinfo/openssl-users >
>
>
>
>
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
