Re: connectEnd and SSL handshake

   Chris and I chatted a little offline and here are our thoughts.

On Tue, Nov 30, 2010 at 12:17 AM, Sigbjørn Vik <sigbjorn@opera.com> wrote:

> On Tue, 30 Nov 2010 02:54:49 +0100, Anderson Quach <aquach@microsoft.com>
> wrote:
>
> In terms of locking down on the specification, stabilizing it's key we
>> focus on stabilizing the interface's behavior. Nic and I's recommendation is
>> to have a definition of connectEnd to be inclusive time taken for of the SSL
>> handshake and SOCKS authentication.
>>
>> Being inclusive of this time prevents large gaps between connectEnd and
>> requestStart in the cases where there may be additional time spent
>> performing SSL handshakes and SOCKS authentication in the timeline. Thus
>> there would be a consistently defined timeline.
>>
>
> I agree that a gap in the timeline would be unwanted, and possibly
> confusing. Though I don't think extending one of the other phases to include
> that gap would be any more wanted or less confusing for Web developers, that
> gap is worhy of a phase of its own.
>
> The socket setup is the closest we get to measuring the latency, which is
> possibly the most important characteristic of a connection.


   +1 that it is really nice if we can have the tcp handshake time expose,
which is why SSL/SOCKS excluded right now.

   If we look at it case by case.
  - SSL: it's good to be able to distinguish tcp-handshake and ssl auth.
  - SOCKS: tcp-handshake happens only between the user and the SOCKS server.
I don't think developer is interested in knowing that and it might bring up
privacy-related questions as well.
So having connectStart/End to include the end-2-end connection time from the
user's perspective makes more sense to me.
  - HTTP proxy: tcp handshakes only between the user and the proxy. But the
browser might not know about the proxy at all so I am not sure if we could
do any better.




> Without a good grip on the latency, it is very hard to divide the
> connection into the socket creation and handshake/authentication, so the
> combined value is then of little value, as well as any other measurements
> which depend on the latency. That the connection timing no longer is used
> the same way on SSL, might also be confusing to developers. Not to mention
> that the handshake/authentication timing itself is interesting, which also
> cannot be seen from timing information where it is joint with the socket
> setup.
>
>
> As IE is abstracted from the inner workings of the network layer,  it would
>> be non-trivial to get the timing information for the SSL handshake and SOCKS
>> authentication.  This phase can always be added at a later time if deemed
>> important.
>>
>
> I understand the complexities of implementation. The definition of phases
> cannot be changed later, but we might add new phases. If we plan to add such
> phases later, we should at the very least plan for them now (to ensure the
> final wording can be non-confusing), we should even make them optional (MAY)
> now.
>
> E.g. connectionStart->socketEnd->handshakeStart->connectionEnd, where
> socketEnd is defined as follows:
> When the socket is fully established, before any communication across the
> socket is started (e.g. SSL handshake or SOCKS authentication). User agents
> which do not have easy access to this information MAY return the value of
> connectionEnd instead. Which value a user agent returns should be documented
> in the flag socketSeparateFromHandshake.
>

     Mostly sounds good, except that, in SOCKS, socketEnd to include SOCKS
authentication? i.e., socketEnd == connectionEnd.

cheers,
Zhiheng



>
> --
>  Sigbjørn Vik
> Quality Assurance
> Opera Software
>
>