Re: [L2tpext] draft-ietf-l2tpext-l2tphc-04.txt
Tmima Koren <tmima@cisco.com> Sun, 17 March 2002 16:23 UTC
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04340 for <l2tpext-archive@odin.ietf.org>; Sun, 17 Mar 2002 11:23:25 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26872; Sun, 17 Mar 2002 11:21:39 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26846 for <l2tpext@optimus.ietf.org>; Sun, 17 Mar 2002 11:21:37 -0500 (EST)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04265 for <l2tpext@ietf.org>; Sun, 17 Mar 2002 11:21:34 -0500 (EST)
Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g2HGL6h02329; Sun, 17 Mar 2002 08:21:07 -0800 (PST)
Received: from tmima-w2k.cisco.com (sjc-vpn2-205.cisco.com [10.21.112.205]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id ACC84408; Sun, 17 Mar 2002 08:20:39 -0800 (PST)
Message-Id: <4.3.2.7.2.20020317081722.03541b98@mira-sjcm-2.cisco.com>
X-Sender: tmima@mira-sjcm-2.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Sun, 17 Mar 2002 08:20:46 -0800
To: "W. Mark Townsley" <townsley@cisco.com>
From: Tmima Koren <tmima@cisco.com>
Subject: Re: [L2tpext] draft-ietf-l2tpext-l2tphc-04.txt
Cc: l2tpext@ietf.org
In-Reply-To: <15507.59111.362145.289310@ebooth-linux.cisco.com>
References: <3C939787.C58C45A1@cisco.com> <200203160023.g2G0NnL02819@cichlid.adsl.duke.edu> <15507.17272.686862.195678@ebooth-linux.cisco.com> <3C939787.C58C45A1@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Sender: l2tpext-admin@ietf.org
Errors-To: l2tpext-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Layer Two Tunneling Protocol Extensions <l2tpext.ietf.org>
X-BeenThere: l2tpext@ietf.org
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 > > > > 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 _______________________________________________ L2tpext mailing list L2tpext@ietf.org https://www1.ietf.org/mailman/listinfo/l2tpext
- [L2tpext] draft-ietf-l2tpext-l2tphc-04.txt Thomas Narten
- RE: [L2tpext] draft-ietf-l2tpext-l2tphc-04.txt Daniel Feldman
- Re: [L2tpext] draft-ietf-l2tpext-l2tphc-04.txt Skip Booth
- Re: [L2tpext] draft-ietf-l2tpext-l2tphc-04.txt W. Mark Townsley
- Re: [L2tpext] draft-ietf-l2tpext-l2tphc-04.txt Tmima Koren
- Re: [L2tpext] draft-ietf-l2tpext-l2tphc-04.txt Skip Booth
- Re: [L2tpext] draft-ietf-l2tpext-l2tphc-04.txt Tmima Koren
- Re: [L2tpext] draft-ietf-l2tpext-l2tphc-04.txt W. Mark Townsley
- Re: [L2tpext] draft-ietf-l2tpext-l2tphc-04.txt Tmima Koren