Re: l2tp as ipsra solution

["Scott G. Kelly" <skelly@xxxxxxxxxxxx>]

Skip Booth wrote:
> 
> On Wed, 14 Jun 2000, Moshe Litvin wrote:
> 
> > Bernard,
> >
> > I agree with Scott that bytes-on-the-wire is only part of the overhead.
> >
> > The problem is that you are comparing raw IPsec (optimized for simplicity
> > and speed) with compressed (optimized for size) L2TP. You are not comparing
> > apples to apples.
> 
> We have had this overhead discussion on the IPsec mailing list previously.  I
> have argued and will continue to argue that the L2TP HC and PPP AFC/PFC should
> not impact the pps throughput of and L2TP/PPP implementation.  In fact since
> L2TP HC runs directly on top of IP this is potentially a slight optimization
> since you only have to look inside 2 headers (IP/L2TP) instead of 3
> (IP/UDP/L2TP).  I can tell you for a fact that PPP PFC/AFC do not have any
> impact on our switching performance.

I'll try this one last time: Moshe's point refers to a native ipsec
implementation. Yours refers to a system which already implements
ppp/l2tp. Lets not waste time talking about how easy it is to
buy/download ppp/l2tp. The point is that you are increasing the code
path that packets must travel through. In the case of header
compression, this my not occur for all packets, but overall, there is an
increase. This is increased overhead both in terms of processing and in
terms of memory usage for the protocol control structures. This isn't an
overwhelming impediment in and of itself, but it should not be ignored.


> I think the real argument here might be the fact that the industry is seeing
> more and more hardware offload of IPsec which allows not only the crypto
> portions of IPsec to be offloaded but the filtering/conformancy checks as well.
> I am not aware of any of these hardware offload designs which support L2TP
> natively so you could argue some performance penalty there.  But this really
> shouldn't be a point of debate for this working group since this is really just
> an implementation detail which can be easily overcome.  So IMO, if the bits on
> the wire overhead is the same (which it is, as Bernard pointed) then we should
> just quit bringing up this point.

Actually, Bernard pointed out that the increase is very small - not that
the bits on the wire overhead is the same.

<much trimmed...>

I agree that we need to solidify on requirements.

Scott