RE: [L2tpext] draft-ietf-l2tpext-l2tphc-04.txt
"Daniel Feldman" <daniel@ic4ic.com> Sat, 16 March 2002 07:25 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 CAA29747 for <l2tpext-archive@odin.ietf.org>; Sat, 16 Mar 2002 02:25:01 -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 CAA03315; Sat, 16 Mar 2002 02:23:19 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA03290 for <l2tpext@ns.ietf.org>; Sat, 16 Mar 2002 02:23:17 -0500 (EST)
Received: from exchange.Ic4ic.com ([194.90.135.194]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA29723 for <l2tpext@ietf.org>; Sat, 16 Mar 2002 02:23:13 -0500 (EST)
Received: through eSafe SMTP Relay 1015254523; Sat Mar 16 09:27:07 2002
content-class: urn:content-classes:message
Subject: RE: [L2tpext] draft-ietf-l2tpext-l2tphc-04.txt
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Date: Sat, 16 Mar 2002 09:21:22 +0200
X-MIMEOLE: Produced By Microsoft Exchange V6.0.4417.0
Message-ID: <88BC9E379956AE4DB689CC5FF6F5A43D02DECA@exchange.Ic4ic.com>
Thread-Topic: [L2tpext] draft-ietf-l2tpext-l2tphc-04.txt
Thread-Index: AcHMgppX6NTJi2cLS3CnVUVHhUAJHwAN7Fqw
From: Daniel Feldman <daniel@ic4ic.com>
To: Thomas Narten <narten@us.ibm.com>, l2tpext@ietf.org
Cc: "Tmima Koren (E-mail)" <tmima@cisco.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id CAA03291
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
Content-Transfer-Encoding: 8bit
The answers: 1) It would be used in the UMTS Radio Access Network (UTRAN), bewteen a Node B and the RNC. This network is normally owned by one company and is used only for transport of of the Radio Network Layer. The scenario is pretty likely. 2) Firewalls probably won't exist between Node B and RNC 3) Can't 115 be used? And even if not, and a new one is needed, I guess TCRTP is technique very useful in UTRAN, and it depends on L2TPHC. How many UTRAN's will be deplyed? A lot... Regards, Daniel Feldman. -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] Sent: Saturday, March 16, 2002 2:24 AM To: l2tpext@ietf.org Subject: [L2tpext] draft-ietf-l2tpext-l2tphc-04.txt 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%. 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] 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