Subject: 0 byte L2TPHC header and implied PPPMUX

From: Tmima Koren <[email-masked]>
Date: Thu, 07 Sep 2000 18:03:29 -0700

I suggest a few minor changes to the L2TPHC draft draft-ietf-l2tpext-l2tphc-02.txt
to improve bandwidth utilization in special cases.

When the L2TPHC header is 1 byte long, actually only 1 bit is significant: the P (Priority) bit.

If all the packets in the tunnel will have the same priority, the L2TPHC byte is redundant.

We could add to the L2TPHC AVP one more byte (byte 9)
We really need only 2 flag bits:

flag 1:  value 1 means: L2TPHC byte will be omitted
            value 0 means: L2TPHC byte is there, get P (Priority) from the L2TPHC byte

flag 2:  value 1 means all packets have implied P=1
            value 0 means all packets have implied P=0

consult flag 2 only when flag 1 is 1

If the packet in the L2TPHC tunnel is always PPPMUX, there is another useful flag:

flag 3: value 1 means 'PPPMUX only'
           value 0 means: any PPP packet

When flags 1 and 3 are on (=1), both L2TPHC header and PPPMUX protocol id can be omitted 
PPP packets that have a different priority or that are not PPPMUX can still be sent in the tunnel using the UDP/L2TP format, same as the L2TP control packets

TCRTP (Tunneled Compressed multiplexed RTP) can benefit from these changes: the tunneling overhead will be reduced by 2 bytes.

Tmima

---

From: Tmima Koren <[email-masked]>
Date: Thu, 14 Sep 2000 01:40:08 -0700

Hi
Since there was no feedback from the lists about this issue, can we update the draft with the suggested changes?
(3 flags in byte 9 of L2TPHC AVP)
Thanks,
Tmima

---

From: Tmima Koren <[email-masked]>
Date: Thu, 14 Sep 2000 10:15:15 -0700

At 08:44 AM 9/14/00 -0700, Andy Valencia wrote:
>[Tmima Koren <[email-masked]> writes:]
>
>I'm concerned with this one.  Since L2TPHC is basically useless except for
>payload, what you've achieved with this flag is to ensure that your control
>traffic will be interrupted if you *ever* permit all payload traffic to be
>given preference by choosing P=1.  My experience is that this will make your
>link unworkable.  And no, using the UDP side doesn't help, since priority is
>(and should be) global to the PPP connection.
>
>I would suggest that when omitting the L2TPHC header entirely, that P=0
>always be the mode of operation.  This shouldn't affect your TCRTP mode of
>operation, because the only thing aside from those payload packets would be
>control packets which should be given priority anyway (and they can go via
>UDP).

In the typical case of a TCRTP tunnel both ends of the tunnel are tied to virtual PPP interfaces.
RTP packets arrive to one side, compressed and tunneled to the other side where they are decompressed and routed to their destination.
Those RTP packets carry voice and may have certain priority. Those packets should regain their priority when they leave the tunnel.
Can this be done with P=0?

>How about A/C fields?  Isn't it a little weird that a field in the middle of
>the PPP packet is coming and going based on this, but the bytes in front
>depend on PPP negotiation?
>
>Also, why hard-wire it to PPPMUX?  Why not include the implicit protocol
>value, so that these savings could apply to IP-only connections which
>weren't using PPPMUX and/or TCRTP?

I thought about this option. The difference is that the PPPMux protocol ID at the head of the packet really acts as a flag to indicate that there is more then one packet in this packet..
but each multiplex carries its own PPP protocol ID.
If you think it's ok to generalize for any protocol, I support that.

Tmima

> >>PPP packets that have a different priority or that are not PPPMUX can still b
> >e sent in the tunnel using the UDP/L2TP format, same as the L2TP control packe
> >ts
> >>TCRTP (Tunneled Compressed multiplexed RTP) can benefit from these changes: t
> >he tunneling overhead will be reduced by 2 bytes.
>
>I guess I'm OK with a 0-byte L2TPHC header option (subject to a nod from the
>chair).  I'd sure like to hear from some people (not just infer something
>from silence) on the PPP header aspect.
>
>Andy Valencia