Re: [Stackevo-discuss] New Version Notification for draft-welzl-irtf-iccrg-tcp-in-udp-00.txt

Alexandre Petrescu <> Fri, 25 March 2016 15:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3CB6012D666 for <>; Fri, 25 Mar 2016 08:04:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.333
X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IKmY5seEKf8y for <>; Fri, 25 Mar 2016 08:04:49 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D988112DB03 for <>; Fri, 25 Mar 2016 08:04:48 -0700 (PDT)
Received: from ( []) by (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u2PF4kRK003757 for <>; Fri, 25 Mar 2016 16:04:46 +0100
Received: from (localhost []) by localhost (Postfix) with SMTP id DFBB22052FF for <>; Fri, 25 Mar 2016 16:05:37 +0100 (CET)
Received: from ( []) by (Postfix) with ESMTP id D7B24202779 for <>; Fri, 25 Mar 2016 16:05:37 +0100 (CET)
Received: from [] ( []) by (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u2PF4jDf032174 for <>; Fri, 25 Mar 2016 16:04:46 +0100
References: <> <> <> <> <> <> <>
From: Alexandre Petrescu <>
Message-ID: <>
Date: Fri, 25 Mar 2016 16:04:45 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [Stackevo-discuss] New Version Notification for draft-welzl-irtf-iccrg-tcp-in-udp-00.txt
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IP Stack Evolution Discussion List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 25 Mar 2016 15:04:51 -0000

Le 25/03/2016 09:12, Michael Welzl a écrit :
>> On 24. mar. 2016, at 18.46, Joe Touch <> wrote:
>> On 3/24/2016 1:20 AM, Michael Welzl wrote:
>>>> On 24. mar. 2016, at 00.52, Joe Touch <> wrote:
>> ...
>>>> Having one uniform layer at which multiplexing occurs makes
>>>> things easy. Having two means you have to wonder what the
>>>> other is doing all the time and whether the two correlate.
>>> Is this a real practical problem related to this draft?
>> It is a real practical problem anytime you tunnel.
> Even when the method avoids that packets grow in size?

The size of the tunnelled packets may not be as big as expected problem.
  For example, additional 40bytes on wireless are not that bad as
initially expected, simply because the total size is already around
1280bytes before tunneling.

On another hand, this problem of multiplexing at multiple levels makes
it that there is no 'traceroute' program that meaningfully reports
number of hops through tunnels.  This is a universal tool for network 
debugging, maybe as loved as ping is.

Overlay networks grow for a while and then get levelled down into
'native' multiplexing level if I can say so.  For example IPv6 tunnels
over an IPv4 world moved to IPv6 native (3ffe disappeared a while back
and 6to4 recently; each had a different way of relating two multiplexing

For TCP in UDP there would be a myriad ways of mixing the slow
intelligence of TCP with the quick dumbness of UDP.  After trying them
all would one come back to TCP and UDP side-by-side as before?  Why not?

Is TCP-in-UDP as reliable as TCP?  Or is it more subject to packet loss
and longer retries?

Is TCP-in-UDP useful for video streaming from constrained devices, as
useful as UDP is?

Does TCP-in-UDP require rendez-vous points?


> I’m surprised but I’m not going to debate this further: you provided
> a useful pointer (the tunnels draft in INTAREA), I’ll have to take a
> look and try to understand the problem. Anyway I agree that a
> solution like the v6 flow labe that Tom Herbert suggested is nicer; I
> have nothing at all against that and now plan to incorporate it in
> the next version of the draft, for the v6 case.
> As for the congestion control related bits of your email, I made a
> mistake: I started this off saying “let’s discuss this in ICCRG”,
> but then I follow up a discussion here on stackevo. This is purely
> about congestion control, so it really belongs there. My next email
> in this matter will go to you, cc iccrg.
> Cheers, Michael
> _______________________________________________ Stackevo-discuss
> mailing list