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: Andy Valencia <[email-masked]>
Date: Thu, 14 Sep 2000 08:44:29 -0700

[Tmima Koren <[email-masked]> writes:]

>>             value 0 means all packets have implied P=0

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

>>When flags 1 and 3 are on (=1), both L2TPHC header and PPPMUX protocol id can

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?

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

---

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

>control packets which should be given priority anyway (and they can go via

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?

>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

---

From: "W. Mark Townsley" <[email-masked]>
Date: Fri, 15 Sep 2000 12:13:28 -0400

Tmima,

I am just getting around to reading this thread myself, so a week is
really not a lot of time for people to consider this. I would like to
hear from others. Paolo? 

To summarize, the current l2tphc provides a 1, 2 or 3 byte header and
now we need to consider a 0 byte header. Bandwidth is precious, the more
flexible the header, the more difficult it is to switch. Our variable
length l2tp header is no joy to switch as is. That said, you know your
market better than I and if you have to get rid of this byte, even with
the processing cost, so be it. I have some new concerns about this first
byte in general that have come up during my most recent hard look at
this.

The first byte of the l2tphc header carries more than the P bit of
course, it carries at least one bit for future use and a few more bits
which are essentially static for all packets. These bits may be more
precious that we think. Given the number of suggestions for changing
this header and the ways it which it is being used that were never
dreamed of in the beginning (l2tphc was really designed for voluntary
tunnels across slow dialup links which have yet to be implemented, where
it *is* being deployed today is on ATM networks and voice applications!)
I would not dare to guess what will be next. Further, we may wish to
carry a uncompressed version of L2TP directly over IP at some point and
Ip protocol IDs are hard to come by. So, I think the static bits should
be put to better use, and a version field seems to be in order so that I
can sleep well at night.

This is what I would like to see in the first byte:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |T|P|I|J|x|x| ver |  Session ID...             |  PPP packet... |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

T,P,I,J are as defined in the l2tphc spec. ver is 1 (or 2 to match l2tp
if you like). 

As for the compression of the first byte via l2tphc, as long as one side
can always force a peer to include this byte if need be then I am OK
with its removal. This has to be a very strong MUST though as it is the
local box that knows if it is going to need this first byte to multiplex
l2tphc with other l2tp or l2tphc versions, not its peer. It should be
very explicit that this is the case (e.g. An l2tphc implementation MUST
be able to send the header format requested by its peer... and then
perhaps even an explanation of why).

More comments below on the mechanisms. Some of these concerns certainly
overlap with Andy's.

>             value 0 means all packets have implied P=0

Since we now have potentially more information in the first byte,
perhaps you should compress it away in a general manner. A new AVP which
defines what the static byte should look like would accomplish this.
e.g. something like this in the AVP:

       0 1 2 3 4 5 6 7 8 
      +-+-+-+-+-+-+-+-+-+
      |T|P|I|J|x|x| ver |
      +-+-+-+-+-+-+-+-+-+

...which sets the proper bits that are "always on" for this session
(and, really, the entire box!)

I would include cautionary text about setting the P bit for all packets
as Andy pointed out (perhaps even stating that it MUST be 0), as well as
the loss of functionality for prioritizing LCP echos in general. 

> 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

This actually falls nicely in the new Service Type model. As soon as
Suhail and Danny finish this up (its my fault, I keep sending it back to
them with corrections) then you will have a framework to identify a new
Service Type for TCRTP/PPPMUX. PPPMUX at least is really a different
framing method and protocol for l2tp so it should be treated as such.
You will need to write a draft identifying this new service type. Nice
thing is that you get l2tp or l2tphc functionality to boot. It also
provides a good place to talk about any pppmux/rtp/l2tphc concerns, as
well as a vehicle for idenifying any specific new avps you might need
for the session that you have not thought of yet.

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

Some of the lengths (no pun intended) we go to for a byte or two still
amaze me.

---

From: Andy Valencia <[email-masked]>
Date: Sat, 16 Sep 2000 08:46:01 -0700

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

>be put to better use, and a version field seems to be in order so that I

But but but... the approach I was trying to take was the version fields
(being invariant) would belong in the L2TPHC *AVP*'s.  So version--like any
other negotiation-phase parameter--do not take bits from the payload.

>This is what I would like to see in the first byte:

Is it just me, or is that a 9-bit byte? :->

>T,P,I,J are as defined in the l2tphc spec. ver is 1 (or 2 to match l2tp

If you want a version field for L2TPHC, let me define Yet Another AVP!

>perhaps even an explanation of why).

Understood.  I can be sure to strengthen that verbage.

>e.g. something like this in the AVP:

Do you want the AVP to say "This is a version 0 format L2TPHC header"?  Or
do you actually want a general bit assignment description (bleh)?

Andy

---

From: "W. Mark Townsley" <[email-masked]>
Date: Sat, 16 Sep 2000 14:27:20 -0400

> other negotiation-phase parameter--do not take bits from the payload.

Unless we have another l2tp header variant come along that we would like
to carry on protocol ID 115. l2tphc only leaves one bit to make the
distinction. Utilizing AVPs to determine the l2tp version assumes that
you can read the session ID, lookup state, and identify the l2tp version
for that packet. This is fine when the session id is in a known location
in the header, but if I have a completely different header from that
defined in l2tphc I am out of luck. 

Since you are defining a completely new header anyway, I don't see much
benefit it not allowing the Offset, Sequence and Length bits to be put
to good use (or at least reserved for good use). Really, the ver field
is no different than using the I and J bits to identify presence of the
one or two byte session ID that l2tphc does now. We could simply leave
the bits reserved or call them something else if you like.

> Is it just me, or is that a 9-bit byte? :->

Whoops. Just remove one of the x's here.

---

From: Bruce A Thompson <[email-masked]>
Date: Tue, 19 Sep 2000 04:05:09 -0700

Sorry for the late response here. I just went through this thread.

>(and should be) global to the PPP connection.

I'm trying to understand this issue a little better.

I assume normally, the P bit in the L2TP header would be mapped to IP precedence/DSCP at IP level. It sounnds like you are saying that when we negotiate for the P bit using the L2TPHC AVP, we are negotiating for the PPP session and not for the L2TPHC connection. However, L2TPHC does not preclude sending uncompressed L2TP packets down the UDP side. These frames will have the P bit set in them. If the P bit is negotiated using the L2TPHC AVP, are you saying that it should be ignored in uncompressed L2TP frames?

>weren't using PPPMUX and/or TCRTP?

After thinking about PPPMUX negotiation using L2TP AVP negotiation, I think there's a layer violation here. PPPMUX is supposed to be negotiated using LCP. If we want to get rid of the PPPMUX protocol ID in the encapsulation, then why not negotiate this using another LCP option for PPPMUX?

My bet is that the PPPEXT working group would accept this option. If PPPMUX was negotiated to not include the PPPMUX protocol ID, then the PPPMUX encapsulation would now not be RFC 1661 compliant. If this is an important option for bandwidth savings with multiplexed encapsulations, then it should be important for both L2TP and PPP.

I think that this option should be proposed in PPPEXT and not as an extension to L2TP.

         Bruce T

>from silence) on the PPP header aspect.

Bruce Thompson
Cisco Systems : IOS Products
email: [email-masked]
office: (408)527-0446
home office: (408)868-0112
San Jose, CA

---

From: Andy Valencia <[email-masked]>
Date: Sat, 23 Sep 2000 12:37:26 -0700

[Bruce A Thompson <[email-masked]> writes:]

>I assume normally, the P bit in the L2TP header would be mapped to IP preceden
>ce/DSCP at IP level.

No.  This is packet queueing on the transmitter of an HDLC device carrying
PPP.

>After thinking about PPPMUX negotiation using L2TP AVP negotiation, I think th
>ere's a layer violation here. PPPMUX is supposed to be negotiated using LCP. I
>f we want to get rid of the PPPMUX protocol ID in the encapsulation, then why 
>not negotiate this using another LCP option for PPPMUX?

Because we're not talking about removing the PPP protocol ID.  We're talking
about L2TP not carrying it across the link, because it's implicitly
understood, and can be inserted after the PPP packet (sans protocol ID) has
traversed the L2TP link.  So this is an L2TP(HC)-only consideration.  PPP
continues to see what it always saw.  And you can't do it at the PPP level,
because then there'd be no way for NCP (not even LCP) to talk across the
link--which PPPEXT would assuredly reject!

Andy Valencia