IETF Logo Mail Archive

Re: UDP encaps for SCTP and SCCP

<L.Wood@surrey.ac.uk> Mon, 26 April 2010 20:34 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 9C5933A68F6; Mon, 26 Apr 2010 13:34:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.72
X-Spam-Level:
X-Spam-Status: No, score=-4.72 tagged_above=-999 required=5 tests=[AWL=-0.721, BAYES_50=0.001, 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 f7L6Q9XbZtcP; Mon, 26 Apr 2010 13:34:28 -0700 (PDT)
Received: from mail82.messagelabs.com (mail82.messagelabs.com [195.245.231.67]) by core3.amsl.com (Postfix) with ESMTP id 7981A3A69ED; Mon, 26 Apr 2010 13:34:27 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: L.Wood@surrey.ac.uk
X-Msg-Ref: server-11.tower-82.messagelabs.com!1272314054!8210409!1
X-StarScan-Version: 6.2.4; banners=-,-,-
X-Originating-IP: [131.227.200.43]
Received: (qmail 22576 invoked from network); 26 Apr 2010 20:34:14 -0000
Received: from unknown (HELO EXHT022P.surrey.ac.uk) (131.227.200.43) by server-11.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 26 Apr 2010 20:34:14 -0000
Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.69]) by EXHT022P.surrey.ac.uk ([131.227.200.43]) with mapi; Mon, 26 Apr 2010 21:34:14 +0100
From: L.Wood@surrey.ac.uk
To: jukka.manner@tkk.fi
Date: Mon, 26 Apr 2010 21:34:14 +0100
Subject: Re: UDP encaps for SCTP and SCCP
Thread-Topic: UDP encaps for SCTP and SCCP
Thread-Index: Acrlf9T5bani/yonSjSntaZF2vwpIA==
Message-ID: <2F336F78-19D9-450A-BDD6-D58B1B108304@surrey.ac.uk>
References: <9693C831-4EE4-4FC5-84A2-083DA16C1CD6@nokia.com> <3513_1271933515_ZZ0L19004IIY5A4Y.00_FD7B10366AE3794AB1EC5DE97A93A37305A2FC3C12@EXMB01CMS.surrey.ac.uk> <4BD5E46E.2070601@tkk.fi>
In-Reply-To: <4BD5E46E.2070601@tkk.fi>
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="us-ascii"
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: Mon, 26 Apr 2010 20:34:29 -0000

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.

L.

> 
> regards,
> Jukka

Lloyd Wood
L.Wood@surrey.ac.uk
http://sat-net.com/L.Wood

v2.23.0 | Report a Bug | By Email