[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPsec and TCP
>Seriously, I suspect that it shouldn't be too big a deal for a smart
>encrypting router to figure out how to squish duplicate TCP segments
>out of it's "waiting for SA" queue.... yes, it's a "layering
>violation" of sorts, but so's header compression.
A while back I proposed a somewhat similar scheme for alleviating TCP
throughput bottlenecks on highly asymmetric network paths, e.g.,
certain cable modems and satellite channels where the reverse link
from the user to the Internet is much slower than the forward link to
the user.
The problem is that the reverse channel can saturate with dataless ACKs
well before the forward link's full capacity is achieved.
My scheme has the bottleneck reverse link router spy on the TCP
packets as they go by. If a new packet arrives for a TCP connection
that already has a packet in the queue, and if the older packet
contains no flags or data, the older packet is replaced with the newer
packet.
The very same scheme should work on any path, including those with
'temporary' bottlenecks such as dialup IP routers and IPSEC tunnels
with long key setup times. It's a layering violation in that you have
an intermediate system spying on end-to-end headers, but it's in the
same relatively benign class as VJ header compression as both leave
the end-to-end TCP checksums alone.
In fact, selective deletion of TCP packets is arguably less of a layer
violation than VJ header compression because the only option the
router has is to drop a packet or forward it unchanged. TCP and other
end-to-end protocols have always been designed to handle packet drops
as they've long been expected behavior of the Internet.
Phil
Follow-Ups:
References: