Subject: Re: [bmwg] measuring TCP connection setup on proxy firewalls

From: Michael Richardson <[email-masked]>
Date: Sun, 01 Apr 2001 14:56:32 -0400

>>>>> "David" == David Newman <[email-masked]> writes:
    David> Here's a proposed workaround. It's not a direct measurement, but
    David> it's the closest thing I can think of:

...

    David> I propose we call connection setup time the interval represented
    David> by (t4-t0).  We don't measure the interval represented by (t5-t4)
    David> but this step is necessary to verify that the proxy connection is
    David> established - i.e., that the ACK sent at t2 wasn't lost.

  yes, this seems to appropriate.
  It does measure:
     1) time to create new proxy state
     2) time to do policy lookup
     3) incremental impact of another connection added to connection table.

  I'm not sure which draft you are dealing with right now, but will you also
include a statement that directly connected client<->server setup time should
be measured? 

] Train travel features AC outlets with no take-off restrictions|gigabit is no[
]   Michael Richardson, Solidum Systems   Oh where, oh where has|problem  with[
]     [email-masked]   www.solidum.com   the little fishy gone?|PAX.port 1100[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [

_______________________________________________
bmwg mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/bmwg

---

From: "David Newman" <[email-masked]>
Date: Sun, 1 Apr 2001 16:10:47 -0400

> include a statement that directly connected client<->server setup

Hi Michael,

It's the firewall performance measurement methodology ID. And, yes,
client-to-server setup time is DEFINITELY included.

In a private email, someone else suggested another even simpler method than
the one I proposed for proxy setup time: Measure client-to-server setup time
with and without a proxy, and call the delta proxy setup time. I like the
simplicity of that approach -- any reason we *shouldn't* use it instead of
what I proposed?

thanks

dn

---

From: Michael Richardson <[email-masked]>
Date: Sun, 01 Apr 2001 23:07:07 -0400

>> I'm not sure which draft you are dealing with right now, but will you
    >> also include a statement that directly connected client<->server setup
    >> time should be measured?

    David> Hi Michael,

    David> It's the firewall performance measurement methodology ID. And,
    David> yes, client-to-server setup time is DEFINITELY included.

    David> In a private email, someone else suggested another even simpler
    David> method than the one I proposed for proxy setup time: Measure
    David> client-to-server setup time with and without a proxy, and call the
    David> delta proxy setup time. I like the simplicity of that approach --
    David> any reason we *shouldn't* use it instead of what I proposed?

  I was suggesting the same thing really.

  Except, that as you pointed out, with a three way handshake, it is hard to
know where the mark points are.

  I prefer your t4-t0 measurement myself.

---

From: Jambi Ganbar <[email-masked]>
Date: Wed, 11 Apr 2001 12:19:00 -0400 (EDT)

I have a few comments on this suggestions.  Inline.

vBNS Engineering
(703) 886 1714

On Fri, 30 Mar 2001, David Newman wrote:

> 
> Brooks Hickman and I have been working on the firewall performance
> methodology draft, and a question has come up about measuring TCP connection
> times.
> 
> An issue arises when benchmarking application-proxy type firewalls. These
> involve the setup of two TCP connections for each client request: one
> between client and proxy, and another between proxy and server. It's easy to
> measure overall connection setup time between client and server, and indeed
> this is what is most interesting for end-users. But implementers of
> proxy-based devices are probably very interested in setup time to the proxy
> itself.
> 
> And therein lies the problem. Since TCP connection setup involves an odd
> number of messages (syn, syn/ack, ack), a handshake that begins on the
> client ends on the proxy. Few if any proxies are also test instruments, so
> it's not possible to make a direct measurement of client-to-proxy connection
> setup time.
> 
> Here's a proposed workaround. It's not a direct measurement, but it's the
> closest thing I can think of:
> 

> t0: Client sends SYN
> t1: Proxy sends SYN/ACK
> t2: Client sends ACK *** [Client may send payload here]
> t3: Proxy establishes separate connection with server *** [which is the
  same process as t0,t1,t2
> t4: Client sends TCP datagram to server
> t5: Proxy sends ACK of datagram to server
> 
> I propose we call connection setup time the interval represented by (t4-t0).
> We don't measure the interval represented by (t5-t4) but this step is
> necessary to verify that the proxy connection is established - i.e., that
> the ACK sent at t2 wasn't lost.

The connection is truly established when the client acks the syn/ack from
the server.  In order to take a time measurement of the process we need to
measure the time difference between when the first syn is send from the
client and the first ACK is received by the server.  
If the above is true and I believe that it is legal to send payload with
the returned ACK as part of the 3 way handshake, your proposal to use t4-t0
is based on the notion that connection establishment is the instance
of payload exchange which might happen at an earlier time then you
expect.  My suggestion to measure initial syn to initial ack reception
might provide a more accurate time.

> Again, this is not a direct measurement and as such it can't account for
> proxy weirdness like t3 taking a long time. However, it does give us at
> least a half a clue about proxy connection setup time. Comments? Is there a
> better way to do this?

Just my 2 cents.
Jambi

---

From: "David Newman" <[email-masked]>
Date: Wed, 11 Apr 2001 12:41:03 -0400

Hi Jambi,

> might provide a more accurate time.

Measuring "ack reception" isn't possible in the context of application-proxy
type firewalls. The AP firewall isn't itself a test instrument, and as such
it doesn't report with any precision when the ack was received.

The specific problem we're trying to address here concerns ONLY the the
client-to-proxy-firewall connection. I agree that for everything else, we
should be measuring the complete client-to-server roundtrip.

Am I missing something, or were you suggesting some other means of measure
client-to-proxy setup times?

dn