IETF Logo Mail Archive

Re: UDP encaps for SCTP and SCCP

Michael Tüxen <Michael.Tuexen@lurchi.franken.de> Tue, 27 April 2010 18:16 UTC

Return-Path: <Michael.Tuexen@lurchi.franken.de>
X-Original-To: tsvwg@core3.amsl.com
Delivered-To: tsvwg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 098C728C16C; Tue, 27 Apr 2010 11:16:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.71
X-Spam-Level: ***
X-Spam-Status: No, score=3.71 tagged_above=-999 required=5 tests=[AWL=-0.742, BAYES_40=-0.185, HOST_EQ_DIP_TDIAL=2.144, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7WKKX1Cpe3O; Tue, 27 Apr 2010 11:16:01 -0700 (PDT)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 956F63A6B6A; Tue, 27 Apr 2010 11:15:49 -0700 (PDT)
Received: from [192.168.1.190] (p508FBC4D.dip.t-dialin.net [80.143.188.77]) by mail-n.franken.de (Postfix) with ESMTP id 62F5F1C0C0BCE; Tue, 27 Apr 2010 20:15:35 +0200 (CEST)
Subject: Re: UDP encaps for SCTP and SCCP
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset="us-ascii"
From: Michael Tüxen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <2F336F78-19D9-450A-BDD6-D58B1B108304@surrey.ac.uk>
Date: Tue, 27 Apr 2010 20:15:34 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <A5E1FDC0-8DD0-44CA-85BF-F0A364AB000A@lurchi.franken.de>
References: <9693C831-4EE4-4FC5-84A2-083DA16C1CD6@nokia.com> <3513_1271933515_ZZ0L19004IIY5A4Y.00_FD7B10366AE3794AB1EC5DE97A93A37305A2FC3C12@EXMB01CMS.surrey.ac.uk> <4BD5E46E.2070601@tkk.fi> <2F336F78-19D9-450A-BDD6-D58B1B108304@surrey.ac.uk>
To: L.Wood@surrey.ac.uk
X-Mailer: Apple Mail (2.1078)
Cc: dccp@ietf.org, tsv-area@ietf.org, tsvwg@ietf.org
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Apr 2010 18:16:03 -0000

On Apr 26, 2010, at 10:34 PM, <L.Wood@surrey.ac.uk> <L.Wood@surrey.ac.uk> wrote:

> 
> On 26 Apr 2010, at 20:07, Jukka Manner wrote:
> 
>> Hi Lloyd,
>> 
>> I have to object here. :)
>> 
>> On 22.4.2010 13:50, L.Wood@surrey.ac.uk wrote:
>> 
>>> The GUT draft and recreating IP packets strikes me as problematic in implementation, just as much as NATs. I'd rather have a simple IP-in-IP-tunnel (or even GRE) and rely on decap at the endpoints...
>>> 
>> 
>> GUT is not problematic, nor difficult. We have it running on Linux and 
>> works great. Next we'll put it on BSD (should be just a medium update to 
>> the code). I'm hoping to release the implementation as open source 
>> sometime in the future.
>> 
>> Our draft could be much better in explaining the idea clearly. The fact 
>> that we are "creating ip packets" is due to our implementation being a 
>> separate piece of code, a separate service on the OS, easily installed.
> 
> No. You are "_re_creating IP packets" in that you are not carrying the IP header end-to-end, but are carrying minimal state to recreate an approximation of the original IP header. That makes me nervous. (This is not link header compression.)
> 
> You are not encapsulating the IP protocol header, but eviscerating it. You call that "reconstruct the native IP packet" or "rebuild the IP packet".
> 
> http://tools.ietf.org/html/draft-manner-tsvwg-gut-01
> (can I suggest a spelling checker for the typos?)
> 
> The summary benefits you state in section 8 work for a normal UDP tunnel, and with rather less complexity.
> 
> On a related note, I spent years dealing with proponents of SCTP, and yet never encountered any actual we-chose-to-use-SCTP end users. So, are there any actual DCCP users out there?
> 
> All this effort to save a few bytes tunnelling complex protocols that still won't be used? Pointless.
> 
>> The functionality could be as well be integrated into the IP stack, but 
>> that would be somewhat more challenging.
> 
> ...and won't happen.
The SCTP/UDP encapsulation is implemented in FreeBSD and part of the SCTP kernel
implementation for Mac OS X.

Best regards
Michael 
> 
> L.
> 
>> 
>> regards,
>> Jukka
> 
> Lloyd Wood
> L.Wood@surrey.ac.uk
> http://sat-net.com/L.Wood
> 
> 
> 
>

v2.23.0 | Report a Bug | By Email