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

[Thomas Narten <[e-mail]>]

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
[e-mail]
https://www1.ietf.org/mailman/listinfo/l2tpext