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