[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Heartbeats Straw Poll
On Tue, 8 Aug 2000, Michael Richardson wrote:
>
> >>>>> "Jan" == Jan Vilhuber <vilhuber@cisco.com> writes:
> Jan> We must agree to disagree then. it's far from 'overhead'. Hwo would
> Jan> YOU feel if you got charged for something that you didn't do?
>
> How will you explain:
>
> a) ESP+IP overhead
> b) IKE overhead
> c) banner ads on yahoo.com
>
That's all part of the traffic originated by the user. If they don't like
paying for yahoo banner ads, don't go to yahoo, or get an ad-blocker.
IKE overhead isn't part of the ipsec SA, and wouldn't be counted anyway.
ESP+IP is also part of a packet on behalf of the user. But of course it's
easy enough to count only the data part of the ESP+IP packet. Way easier than
filtering out pings (which are NOT on the user's behalf; although arguably
it's a service that a user would pay for, if they really wanted it), which
can and do add up (I know customers who really really want to run our
keepalives at some absurd interval; I just know the next thing they'd ask for
is to NOT count things like the pings they'd send every second).
I don't have a STRONG opposition to pings, BTW (as long as they don't get a
separate SA like one proposal proposed). Afterall, if you're using routing to
do this whole link-state assessment, then that would be network traffic
counted against the volume of the SA as well (OSPF HELLO's versus pings.. no
real difference for the SA). I'm just pointing out that it's not QUITE as
straightforward as you claim (at least in the minds of some overly
penny-pinching customers; I point to the radius accounting attribute
pre-authen-bytes or whatever it was called as evidence).
I've seen some pretty nice ideas so far, which may work as well. Let's keep
up the discussion of alternative means to keepalives...
jan
--
Jan Vilhuber vilhuber@cisco.com
Cisco Systems, San Jose (408) 527-0847
Follow-Ups:
References: