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

From: "W. Mark Townsley" <[email-masked]>
Date: Tue, 15 Feb 2000 17:40:21 -0500

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]

---

From: Andy Valencia <[email-masked]>
Date: Tue, 15 Feb 2000 14:54:53 +0000

Thanks,
Andy Valencia
[email-masked]

---

From: Andy Valencia <[email-masked]>
Date: Tue, 15 Feb 2000 16:36:00 +0000

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

>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).

>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

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 16 Feb 2000 01:23:08 -0800

>proposal would not entail. Also, no advantage for larger packets.

The focus here is really on VOIP, right? Even with the full L2TP
header, for 700 octet packets the overhead is not a very big
percentage. So not being able to handle larger packets in PPPMUX 
isn't that much of a liability. 

Looks to me like PPPMUX is most effective at low bit rates (< 56 Kbps)
where the overhead saved might actually be larger than the serialization
time of an uncompressed header. In this case you save both bandwidth
and delay. Also, there's nothing that says that you can't do IP/UDP/RTP
compression within PPPMUX, right? 

Also, I am curious if the presence of the IPSEC header affects any
of these calculations.

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 16 Feb 2000 01:29:44 -0800

>That draft seems to assume that the PPP header is the primary issue.  

Actually, in IPSEC/L2TP, the IPSEC header is an issue. 
PPPMUX gives you savings there by effectively spreading the IPSEC
overhead over multiple packets. L2TPHC doesn't accomplish this. 

>jitter buffering of any carried audio streams.

With IPSEC in the equation the savings are quite a bit larger. And
if we are talking about low bit rates, then I don't think that there
will be a jitter buffer effect. 

So I think that we might want to look at this some more.

---

From: "W. Mark Townsley" <[email-masked]>
Date: Wed, 16 Feb 2000 06:37:54 -0500

> isn't that much of a liability.

Of course, as the size of the packet increases, the advantage of any
type of header compression decreases.

> compression within PPPMUX, right?

Certainly. I believe that was an assumption of one of the applications
presented at the last IETF.

---

From: "W. Mark Townsley" <[email-masked]>
Date: Wed, 16 Feb 2000 06:44:49 -0500

> So I think that we might want to look at this some more.

One of the current limitations in pppmux is that it can only multiplex
frames smaller than 128 bytes. I believe this could be increased to 256
fairly easily. 512 might be nice as well, but might not be as simple
with the current design. Beyond that the advantages begin to dwindle as
we approach the 1500 byte MTU. 

I have brought this up with the pppmux authors once before, so the
concept should not be entirely new. Copying ietf-ppp for hope of comment
there.

- Mark

---

From: Craig Fox <[email-masked]>
Date: Wed, 16 Feb 2000 07:30:56 -0500

> we approach the 1500 byte MTU.

With the current design, it is not possible to go past 128 bytes.  However,
it occurred to me that a minor mod which would lower the maximum efficient
size to 64 bytes (still above the normal 'small' packet size) would allow
us to multiplex packets up to 16k bytes.  The approach would be to steal
another bit from the length field to identify an extended length field
where the next byte was the rest of the 14 bit length field (two bytes of
length minus two flag bits, one for protocol compression bit and one for
the extended length field flag).  This makes some of the processing more
complex while simplifying other processing since it would no longer be
necessary to flush the multiplexing frame because the next frame to be
added was too long.

What was not clear about the above approach (because I haven't taken the
time to analyze it) was whether it would result in a net savings for
larger (>256 byte) packets that would make it worth reducing the efficiency
of packets between 64 and 128 bytes.

Craig

---

From: Tmima Koren <[email-masked]>
Date: Wed, 16 Feb 2000 12:04:48 -0800

>presented at the last IETF.

That's TCRTP: Tunneled multiplexed CRTP
TCRTP uses L2TPHC to tunnel CRTP packets, optionally multiplexed using PPPMUX.
Tmima