Subject: [L2tpext] draft-ietf-l2tpext-l2tphc-04.txt

From: Thomas Narten <[email-masked]>
Date: Fri, 15 Mar 2002 19:23:49 -0500

The WG has asked to publish this document as a PS, but I have some
questions I'd like to get WG input on first.

General concerns

1) How much use would L2TPHC as described in this document actually
   see in practice. It seems to be of limited applicability, given the
   assumptions being made. Specifically, the document says:

   If several simplifying assumptions may be met, it is possible to
   reduce the size of the L2TP encapsulation:

      - The tunnel will not operate through a NAT interface
      - The tunnel uses a single IP address for the life of the tunnel
      - The tunnel's host uses only one public IP network interface
      - There will be only one tunnel between the LAC and the LNS
      - There might be only one session within a tunnel
      - There might be only one protocol active on that session
      - Alignment is not required
      - Packet length is preserved by the IP header

   Where will the compression scheme described in this document be
   deployed, given its restricted applicability?

2) The protocol is firewall hostile, as it's carrying a dynamic
   payload that sits directly on top of IP. There is nothing above the
   IP protocol to filter on, since it may carry an arbitrary raw PPP
   frame. Will firewalls in fact let such traffic through? Should
   they?  How will this impact deployability?

3) The document requires assignment of an IP protocol number, a
   limited resource. If this technique has only limited applicability,
   it would not seem to justify assignment of an IP protocol
   number. I'd like to better understand  whether an IP port number
   can be justified for this application/usage

4) Is this use of compression compatable with IPsec? I.e., do existing
   IPsec implementations support protocols other than TCP/UDP  when
   run over IP? In this case, L2TP is being run directly above IP.

5) How does this compare to other existing, more general compression
   techniques. Sure, you can always squeeze a few more bytes by having
   something very application-specific, but in general this is not
   viewed as a good thing, especially when (as in this case) an IP
   protocol number is needed and the usage applies to only limited
   configurations where L2TP is in use. How does this compare with,
   say, RFC 3095 compression.

Note: I also don't quite agree with "5. Efficiency Considerations".

>    Some rough calculations will illustrate the environments in which
>    L2TPHC may be beneficial.  Overhead as a percentage of the carried
>    traffic will be calculated for a typical packet size involved in bulk
>    data transfer (700 bytes), and the canonical 64-byte ``small IP
>    packet''.  Percentages will be rounded to the nearest whole number.
>    Overhead is tallied for an IP header of 20 bytes, a UDP header of 8
>    bytes, an L2TP header of 8 bytes, and a PPP encapsulation of 4
>    bytes.

> 
>    The worst case is a 64-byte packet carried within a UDP L2TP header.
>    The 64 bytes of payload is carried by an overall header of 40 bytes,
>    resulting in an overhead of 63%.  With the larger payload size of 700
>    bytes, the header is amortized over many more bytes, reducing the
>    overhead to 6%.

Seems to me that the overhead being listed is misleading. If the
original payload is 64 bytes (this includes a fully formed TCP/IP/PPP
packet with its own IP header), and one then encapsulates it within
L2TP, you are adding 36 bytes of overhead by using l2tp. That's an
overhead of 36/(68+36) = 34% (when compared to the no l2tp case).

I.e., counting the original IP/PP headers as part of "overhead" is
misleading because they would get sent anyway, and those are not being
compressed away by this technique (at least as I understand things).

>    With L2TPHC, the UDP header is absent, the L2TPHC header is 0 bytes
>    for the most compact case, and the 4 bytes of PPP encapsulation have
>    been deleted.  Overall size is thus 20 bytes of IP header.  The small
>    packet now suffers an overhead of only 31%, and the larger packet 3%.

So now your overhead  is more like 20/(64+20) = 23%.

So yes, there is a reduction in overhead, but its not 63% to 31%, its
more like 34% to 23%.

Thomas

_______________________________________________
L2tpext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/l2tpext

---

From: Skip Booth <[email-masked]>
Date: Sat, 16 Mar 2002 08:07:04 -0500

> So yes, there is a reduction in overhead, but its not 63% to 31%, its

With L2TPv3 coming along the difference is even less.  Since L2TPv3
proposes a 4 byte L2TP header in the simplest case and it runs directly on
top of IP, the total header size is 24 bytes minimum.  So now we are down
to a 4 byte difference in header sizes.  IMO, that's not worth proposing a
new RFC for and allocating a IP protocol number for.

My 2c.

-Skip

---

From: "W. Mark Townsley" <[email-masked]>
Date: Sat, 16 Mar 2002 20:05:43 +0100

Please see inline.

Thanks,

- Mark

> >    deployed, given its restricted applicability?

I think l2tphc does a nice job of identifying all of the reasons why you may NOT
want to run with most of your l2tp and ppp header missing. And, yes, there are a
lot of very good reasons not to do this. The efficiency in number of bytes on
the wire has to be of such overriding concern that none of these items remain
significant. To not point these out would be a very bad thing.

> >    they?  How will this impact deployability?

Agreed. Daniel identified that the intended application does not require NAT
friendliness. If l2tphc doesn't underscore this loudly enough now, it should.

> >    can be justified for this application/usage

We could always resurrect the negotiation of the protocol ID in the l2tphc
setup, as was done in the early versions of the draft. It's not very NAT
friendly, but as Daniel pointed out, the known intended application of l2tphc
doesn't utilize a NAT, and as Thomas pointed out, l2tphc isn't very NAT friendly
anyway (and neither is L2TPv3's IP mode, FWIW). I think I would rather see
L2TPv3 used here instead (see discussion later in this email), but it is still a
possibility.

> >    run over IP? In this case, L2TP is being run directly above IP.

When you stop running over UDP, you lose a very handy selector for demuxing SAs
between like IP address pairs. However, you can still setup an SA based on your
IP address pair alone for the L2TPHC protocol type. Note that this is really no
more limited than, say, running GRE on top of IP and protecting it with IPsec.

> >    say, RFC 3095 compression.

I think Andy's response to this was that RFC3095 didn't exist at the time l2tphc
was written, or even when it first entered last call. If the folks that intend
to use l2tphc (UTRAN?) can use RFC 3095 to achieve the same gains in a more
general manner, great. Personally, I haven't even tried to investigate that and
would be happy to hear why it is or is not applicable.

> > overhead of 36/(68+36) = 34% (when compared to the no l2tp case).

Regarding overhead calculations, I believe Andy already said that he would look
into these as long as there still was support for l2tphc in general. I
understand his desire to not spend any time on the draft at this point, as it
has been tugged back and forth for a long while now. Thanks for a very thorough
job of digging into the details here, Thomas, if you are right then we surely
should have caught this a lot time ago. 

> new RFC for and allocating a IP protocol number for.

Good point, Skip. 

However, one could still utilize the l2tphc mechanisms to whittle down the PPP
framing if necessary, so it is a little more than just the 4 bytes (PPP's
mechanisms can get you down to one byte, but l2tphc gets you to 0 which might be
significant if you are worried about an aligned inner header as well as a
minimal header). Add to this the fact that the PPP over L2TPv3 header has its
own 4 byte header for sequencing and offset (I don't think we have made it clear
that it is not always present, which something l2tphc-like built into the PPP
spec would have to mandate) and the bytes could start to add up.

If there are existing interoperable implementations, or the need to reduce the
l2tp header by the 5-9 bytes that l2tphc provides you on top of the new IP encap
in L2TPv3 for some applications is deemed highly significant (the UTRAN folks
are as good a candidate as anyone to argue this case), then I think we should go
ahead and publish the RFC. 

However, if folks can live with the 4 byte IP encapsulation defined in
draft-ietf-l2tpext-l2tp-base-02.txt, then we could simply (1) add something to
the PPP over L2TPv3 spec that ensures the PPP control word may not be present,
and (2) negotiate away the PPP framing ala l2tphc now. This would be something
that could be folded into the PPP over L2TPv3 spec, or companion spec (perhaps
easily negotiated via L2TPv3's new PW-Type AVP as a separate "compressed PPP"
PW-Type). This would at least have the advantage of fewer L2TP encapsulations to
support overall, and could fit into the L2TPv3 PW model well.

- Mark

---

From: Tmima Koren <[email-masked]>
Date: Sat, 16 Mar 2002 11:57:17 -0800

>would be happy to hear why it is or is not applicable.

RFC3095 (ROHC) can't replace l2tphc:
ROHC is a point to point header compression, like rfc2507, rfc2508 (CRTP)
If the source and destination are multiple hops apart, by using ROHC you 
have to compress/decompress on every link.
Instead the TCRTP proposal (draft-ietf-avt-tcrtp-06.txt) is to use either 
ROHC or CRTP to compress the headers at the source, then use l2tphc to 
tunnel the compressed packet to the destination. This way the header 
compression/decompression happens only once.
You can also use PPPMux (RFC3153) to multiplex several compressed packets 
together, then tunnel the multiplexed packet all the way to the 
destination. This way the overhead of the tunneling header is amortized 
over several payloads.
We are looking here at reducing the overhead of the tunneling headers.
Tmima

---

From: Skip Booth <[email-masked]>
Date: Sat, 16 Mar 2002 19:44:23 -0500

W. Mark Townsley writes:
> However, one could still utilize the l2tphc mechanisms to whittle down
> the PPP framing if necessary, so it is a little more than just the 4
> bytes (PPP's mechanisms can get you down to one byte, but l2tphc gets you
> to 0 which might be significant if you are worried about an aligned inner
> header as well as a minimal header).

Negotiating away the PPP protocol header should be a PPP option not a L2TP
HC feature.  IMO this shouldn't be a part of this draft to start with.

>  Add to this the fact that the PPP over L2TPv3 header has its own 4 byte
> header for sequencing and offset (I don't think we have made it clear
> that it is not always present, which something l2tphc-like built into the
> PPP spec would have to mandate) and the bytes could start to add up.

Since sequencing and offset was never a required part of RFC2661 I think
it's fair to assume that these are not part of the PPP over L2TPv3 draft.

So assuming the negotiation of the PPP protocol off is a separate PPP draft
and we don't need sequencing/offset information for PPPoL2TPv3, we are
comparing a 4 byte L2TPv3 header to a 1 byte L2TPHC header.  Is a new RFC
just to save 3 bytes really worth it?  I'd much rather see the investment
in L2TPv3 which is something we really need in order to solve a much larger
set of problems.

-Skip

---

From: Tmima Koren <[email-masked]>
Date: Sun, 17 Mar 2002 08:20:46 -0800

Can we dedicate some time to discuss this in the WG session?
Thanks,
Tmima

---

From: "W. Mark Townsley" <[email-masked]>
Date: Mon, 18 Mar 2002 05:41:00 +0100

Yes. As long as interested parties are present, and someone can lead the
discussion, there is time.

Thanks,

- Mark

---

From: Tmima Koren <[email-masked]>
Date: Sun, 17 Mar 2002 23:27:50 -0800

Thanks. I'll prepare a short presentation on how we plan to use l2tphc
Tmima