RE: [v6tc] Issue 1: Could we live with UDP encapsulation always o n?
"Soliman, Hesham" <H.Soliman@flarion.com> Wed, 22 December 2004 20:58 UTC
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02821;
Wed, 22 Dec 2004 15:58:57 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71])
by ietf-mx.ietf.org with esmtp (Exim 4.33)
id 1ChDjD-0002z7-Ow; Wed, 22 Dec 2004 16:09:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1ChDMO-0006gu-LG; Wed, 22 Dec 2004 15:45:28 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1ChDIn-0004UC-Ao
for v6tc@megatron.ietf.org; Wed, 22 Dec 2004 15:41:45 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01397
for <v6tc@ietf.org>; Wed, 22 Dec 2004 15:41:42 -0500 (EST)
Received: from mail.flarion.com ([63.103.94.23]
helo=ftmailgfi1.flariontech.com)
by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ChDSW-0002If-DX
for v6tc@ietf.org; Wed, 22 Dec 2004 15:51:49 -0500
Received: from ftmailserver.flariontech.com ([10.10.1.140]) by
ftmailgfi1.flariontech.com with Microsoft
SMTPSVC(5.0.2195.6713); Wed, 22 Dec 2004 15:41:09 -0500
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [v6tc] Issue 1: Could we live with UDP encapsulation always o n?
Date: Wed, 22 Dec 2004 15:41:08 -0500
Message-ID: <A11736FE943F1A408F8BBB1B9F5FE8AD17DD86@ftmailserver.flariontech.com>
Thread-Topic: [v6tc] Issue 1: Could we live with UDP encapsulation always o n?
Thread-Index: AcToNYo4SWcGxfoTRbicmck4ZR3b6QAMEXrQ
From: "Soliman, Hesham" <H.Soliman@flarion.com>
To: "Karen E. Nielsen \(AH/LMD\)" <karen.e.nielsen@ericsson.com>,
<v6tc@ietf.org>
X-OriginalArrivalTime: 22 Dec 2004 20:41:09.0617 (UTC)
FILETIME=[915AC610:01C4E866]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Content-Transfer-Encoding: quoted-printable
X-BeenThere: v6tc@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: v6tc.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/v6tc>,
<mailto:v6tc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/v6tc>
List-Post: <mailto:v6tc@ietf.org>
List-Help: <mailto:v6tc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/v6tc>,
<mailto:v6tc-request@ietf.org?subject=subscribe>
Sender: v6tc-bounces@ietf.org
Errors-To: v6tc-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Content-Transfer-Encoding: quoted-printable
Karen, > Semi-conclusion: > Now worst case 7% "waste" of radio resources > is certainly not negligible business wise, but it should > not be a showstopper. This especially given that the bandwidths > of the radio links are ever increasing AND that preferably > only a small > portion of the traffic over the link will be tunnelling traffic. > Personally, I am much more concerned > with the implementation aspects in end-nodes and routers. => 7 % is a _huge_ overhead. I'm much more concerned about that than implementation issues. Also, depending on the link layer, you might not be able to get the right bearer, given these BW requirements. Additionally, packet classification (if Diffserv is not used in the host) is more difficult. Much worse than that, UDP encapsulation for NAT traversal is very bad in wireless environments because it will usually involve keepalives, which means that a terminal will never go dormant basically....here goes the battery lifetime! Anyway, I think you'll find that 7 % is a showstopper for a lot of people and that they will need to either: - compress it, or - Run native v6. It might be an incentive to run native v6, but until then, it's a problem. Hesham > > I cannot say that any of this is show-stopper candidates, > but all in all > it doesn't make v6-udp-v4 seem very attractive > compared to v6-in-v4 the mechanisms we work with today. > > BR, Karen > > _______________________________________________ > v6tc mailing list > v6tc@ietf.org > https://www1.ietf.org/mailman/listinfo/v6tc > =========================================================== This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies. =========================================================== _______________________________________________ v6tc mailing list v6tc@ietf.org https://www1.ietf.org/mailman/listinfo/v6tc
- RE: [v6tc] Issue 1: Could we live with UDP encaps… Karen E. Nielsen (AH/LMD)
- RE: [v6tc] Issue 1: Could we live with UDP encaps… Pekka Savola
- Re: [v6tc] Issue 1: Could we live with UDP encaps… Ole Troan
- RE: [v6tc] Issue 1: Could we live with UDP encaps… Soliman, Hesham