Re: [BEHAVE] TURN Issue: Preserving bits in the IP header

Lars Eggert <lars.eggert@nokia.com> Mon, 07 January 2008 17:04 UTC

Return-path: <behave-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBvOY-0004fe-Jm; Mon, 07 Jan 2008 12:04:14 -0500
Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1JBvOX-0004fR-C4 for behave-confirm+ok@megatron.ietf.org; Mon, 07 Jan 2008 12:04:13 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBvOX-0004fH-1A for behave@ietf.org; Mon, 07 Jan 2008 12:04:13 -0500
Received: from smtp.nokia.com ([192.100.122.233] helo=mgw-mx06.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JBvOW-0004JY-Gl for behave@ietf.org; Mon, 07 Jan 2008 12:04:12 -0500
Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m07H3oF6001209; Mon, 7 Jan 2008 19:04:09 +0200
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Jan 2008 19:04:05 +0200
Received: from [192.168.255.2] ([10.162.252.187]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Jan 2008 19:04:05 +0200
Message-Id: <6C4E6148-7EDA-4A44-AED2-CFE02B06A341@nokia.com>
From: Lars Eggert <lars.eggert@nokia.com>
To: ext Rémi Denis-Courmont <Remi.Denis-Courmont@nokia.com>
In-Reply-To: <200801030949.41979.remi.denis-courmont@nokia.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v915)
Subject: Re: [BEHAVE] TURN Issue: Preserving bits in the IP header
Date: Mon, 07 Jan 2008 19:04:04 +0200
References: <494C2569-D8B1-4E93-943D-11454FBEDC11@magma.ca> <200801030949.41979.remi.denis-courmont@nokia.com>
X-Mailer: Apple Mail (2.915)
X-OriginalArrivalTime: 07 Jan 2008 17:04:05.0565 (UTC) FILETIME=[4F5A66D0:01C8514F]
X-Nokia-AV: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Cc: behave@ietf.org, ext Philip Matthews <philip_matthews@magma.ca>
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
Errors-To: behave-bounces@ietf.org

On 2008-1-3, at 9:49, ext Rémi Denis-Courmont wrote:
> I don't know what ECN will do for UDP, and I suppose that would not  
> work for
> TCP (since it works in pair with CWR).

ECN is orthogonal to what transport is used. All an ECN mark is is a  
signal from a router on the path that says "I almost dropped this  
packet."

Various transports are free to define various appropriate responses to  
that signal. TCP decided to treat the ECN signal as if there had been  
a loss, but that is only one possibility. For example, a UDP sender  
that was using TFRC to compute a safe rate might decide to reduce its  
send rate when an ECN mark is received. Or a CBR UDP sender might  
decide to stop transmission after receiving ECN marks at a certain  
rate, in order to take load off the network a bit quicker when there  
is congestion.

So ECN marks do need to be preserved, in order to let any intended  
response mechanism kick in.

(Also see draft-briscoe-tsvwg-ecn-tunnel on ECN interactions with  
tunneling.)

Lars

_______________________________________________
Behave mailing list
Behave@ietf.org
https://www1.ietf.org/mailman/listinfo/behave