I'll try to reply in more detail tomorrow; for now, let me say that the network
traffic situation is vastly more complex than you describe.
First, the papers you and Hari cite are for wide-area traffic. IPsec VPNs
will probably have characteristics much more like LAN or site-local traffic.
We don't have reliable data on modern intrasite traffic; the latest good study
I've found is Gusella's, from around 1991 or thereabouts. 75% of WAN traffic
is http; while there is certainly a lot of internal Web use, you'll also see
networked file systems, a lot of email polling and submission, and very many
custom applications. We don't know what this traffic is like.
I do agree that traffic has a bimodal size distribution (in fact, I think I
said so at AES-3); I based my statement in part on the same papers and Web
sites that you mention. And while the average packet size is indeed tending
upwards, there are a number of complicating factors.
First, Path MTU usage is being hindered by firewalls that block the necessary
ICMP messages. Second, packet size is also affected by flow size, and the
average flow is remarkably short. In other words, if you're not sending very
much data, you can't send it in very big packets. (This statement is also
based on measurements of wide-area traffic, and hence is dominated by the
behavior of Web clients and servers. That, in turn, is unlikely to change
until we have many more HTTP 1.1-compliant browsers and servers deployed; that
is happening rather slowly (http://www.research.att.com/~bala/papers/procow-1.ps.gz).
The real question, though, is what the probability is of a packet for one
security association being followed by a packet for another. On this, we have
little data; what we do have suggests to me that we will see rather more
context switches. Raj Jain's work on "packet trains" suggests that large
bursts of data will be sent out in several consecutive packets; depending on
the ACK delay strategy, there will be fewer small ACK packets, and those will
be widely spaced; that in turn allows more room for interleaving. If nothing
else, the shorter transmission time for a small packet will allow gaps in
which other packets may be sent. But how are packet trains affected as they
pass through many hops in today's Internet? We don't know. What about the
effect of TCP congestion control strategies on packet spacing? Again, there
isn't nearly as much data as we'd like.
One last point for tonight. Your third note suggests that it is the total
work that matters, which in turn depends on the average packet size, rather
than the distribution. That, I think, is only true if one has sufficient (and
sufficiently fast) buffers. That is, suppose that a packet arrives for a
different SA, necessitating a key change. That packet has to be buffered
while the new key schedule is computed or loaded. If the packet is short, and
is followed by several more short packets for other SAs, each will be delayed
by this process. Yes, you'll make it up on the next large packet that
arrives; however, the cumulative delay can be significant. Apart from the
buffering, latency is quite important for throughput, and can have bad effects
on real-time traffic, such as voice-over-IP. (I should note that if VoIP
develops as some expect, it will completely change the nature of Internet
traffic.)
Bottom line -- the actual dynamics of network traffic seem to matter quite a
lot, and while we don't know all that we should, I see enough trends that I do
believe that key agility is an important issue.
--Steve Bellovin
