Subject: Re: L2TP header compression, link-by-link?

From: [email-masked]
Date: Fri, 31 Mar 2000 12:57:17 -0800

Andy Valencia wrote:
>
> So what's the WG's instinct on link-by-link compression for L2TP (ala RFC
> 2508)?  We're talking (potentially) about:
>
>         RTP - UDP - IP - PPP - L2TP - UDP - IP - PPP
>         12  + 8   + 20 + 1   + 6    + 8   + 20 + 1      = 76 bytes
>
> flattening into a single RTP-under-L2TP header (two bytes, I think).
>
> This'll probably work out nicely for voluntary tunneling configurations.
> For the ATM model presented in DC, chopping just the outer
> PPP/L2TP/UDP/IP/PPP may suffice per VC (since the concentrator may
> multiplex too many sessions for the CID to handle the variance of the
> inner RTP/UDP/IP).  What does the WG think about a link-by-link L2TPHC
> draft, with RTP-over-L2TP, IP-over-L2TP (so carry the RTP/UDP or whatever
> else it is as payload), and just-L2TP compression options?
>
> It sure won't scale as well on the concentrator side as base L2TP or the
> current L2TPHC drafts.  But header overhead going from 76 to 2 bytes is a
> pretty sweet win for small packet applications like RTP.  Hell, even at
> 1500 byte MTUs you could almost notice it.
>
> - Is there a good reason why this wouldn't work?
> - Should we choose the current L2TPHC approach over this?

We should at least consider the consolidation of multiple, small, PPP
frames (such as RTP) via:

http://www.ietf.org/internet-drafts/draft-ietf-pppext-pppmux-00.txt

However, there may be latency issues with this approach that your
proposal would not entail. Also, no advantage for larger packets.

> - Vice versa?
> Thanks,
> Andy Valencia
> [email-masked]