I Appreciate your response On Tue, Jun 20, 2017 at 2:09 AM, Matt Caswell <m...@openssl.org> 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 <m...@openssl.org > > <mailto:m...@openssl.org>> 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 <m...@openssl.org > <mailto:m...@openssl.org> > > > <mailto:m...@openssl.org <mailto:m...@openssl.org>>> 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 >
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users