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

[Tmima Koren <[e-mail]>]

At 08:05 PM 3/16/2002 +0100, W. Mark Townsley wrote:

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

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


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


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