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

Thomas Narten writes:
> 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%.

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

> 
> Thomas
> 
> _______________________________________________
> L2tpext mailing list
> L2tpext@ietf.org
> https://www1.ietf.org/mailman/listinfo/l2tpext

_______________________________________________
L2tpext mailing list
L2tpext@ietf.org
https://www1.ietf.org/mailman/listinfo/l2tpext