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

[Tmima Koren <[e-mail]>]

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

At 05:41 AM 3/18/2002 +0100, W. Mark Townsley wrote:

>Yes. As long as interested parties are present, and someone can lead the
>discussion, there is time.
>
>Thanks,
>
>- Mark
>
>Tmima Koren wrote:
> >
> > Can we dedicate some time to discuss this in the WG session?
> > Thanks,
> > Tmima
> >
> > At 07:44 PM 3/16/2002 -0500, Skip Booth wrote:
> >
> > >W. Mark Townsley writes:
> > > >
> > > > 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).
> > >
> > >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
> > >
> > > >
> > > > 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


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