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? 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> > > <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 > <https://mta.openssl.org/mailman/listinfo/openssl-users> > > > > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
