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