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

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

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?
- Vice versa?

Thanks,
Andy Valencia
[email-masked]

---

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

["W. Mark Townsley" <[email-masked]> writes:]

>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

That draft seems to assume that the PPP header is the primary issue.  In
fact--especially considering that CRC is not an issue for our
application--it is easily the smallest part of the problem (at one byte
per header).

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

And really saving only a byte or so per packet, and indeed affecting the
jitter buffering of any carried audio streams.

Andy