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

Please see inline.

Thanks,

- Mark

Skip Booth wrote:
> 
> 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?

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.

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

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

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

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.

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

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.

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

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.

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

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. 

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

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

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

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