RE: UDP encaps for SCTP and SCCP

<L.Wood@surrey.ac.uk> Tue, 27 April 2010 18:27 UTC

Return-Path: <L.Wood@surrey.ac.uk>
X-Original-To: tsv-area@core3.amsl.com
Delivered-To: tsv-area@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D96E728C1D5; Tue, 27 Apr 2010 11:27:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.03
X-Spam-Level:
X-Spam-Status: No, score=-6.03 tagged_above=-999 required=5 tests=[AWL=0.569, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 oJpnUcwXchpm; Tue, 27 Apr 2010 11:27:52 -0700 (PDT)
Received: from mail82.messagelabs.com (mail82.messagelabs.com [195.245.231.67]) by core3.amsl.com (Postfix) with ESMTP id 7C26928C23D; Tue, 27 Apr 2010 11:26:34 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: L.Wood@surrey.ac.uk
X-Msg-Ref: server-5.tower-82.messagelabs.com!1272392781!2518232!1
X-StarScan-Version: 6.2.4; banners=-,-,-
X-Originating-IP: [131.227.200.35]
Received: (qmail 31470 invoked from network); 27 Apr 2010 18:26:21 -0000
Received: from unknown (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-5.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 27 Apr 2010 18:26:21 -0000
Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.69]) by EXHT021P.surrey.ac.uk ([131.227.200.35]) with mapi; Tue, 27 Apr 2010 19:26:20 +0100
From: L.Wood@surrey.ac.uk
To: Michael.Tuexen@lurchi.franken.de
Date: Tue, 27 Apr 2010 19:26:22 +0100
Subject: RE: UDP encaps for SCTP and SCCP
Thread-Topic: UDP encaps for SCTP and SCCP
Thread-Index: AcrmNaLdhFsVbWhBQeakpxZGtHM4ZwAAMA7A
Message-ID: <FD7B10366AE3794AB1EC5DE97A93A37305A2FBA2B5@EXMB01CMS.surrey.ac.uk>
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> <A5E1FDC0-8DD0-44CA-85BF-F0A364AB000A@lurchi.franken.de>
In-Reply-To: <A5E1FDC0-8DD0-44CA-85BF-F0A364AB000A@lurchi.franken.de>
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-GB
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: dccp@ietf.org, tsv-area@ietf.org, tsvwg@ietf.org
X-BeenThere: tsv-area@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Transport Area Mailing List <tsv-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tsv-area>, <mailto:tsv-area-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tsv-area>
List-Post: <mailto:tsv-area@ietf.org>
List-Help: <mailto:tsv-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-area>, <mailto:tsv-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Apr 2010 18:27:54 -0000

That's hardly integrated into a shipping IP stack.

FreeBSD may be an SCTP reference implementation, but that's not significant deployment.

-----Original Message-----
From: Michael Tüxen [mailto:Michael.Tuexen@lurchi.franken.de] 
Sent: 27 April 2010 19:16
To: Wood L Dr (Electronic Eng)
Cc: jukka.manner@tkk.fi; dccp@ietf.org; tsv-area@ietf.org; tsvwg@ietf.org
Subject: Re: UDP encaps for SCTP and SCCP

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
> 
> 
> 
>