[conex] 2) False positives of the audit

Mirja K├╝hlewind <mirja.kuehlewind@ikr.uni-stuttgart.de> Mon, 03 June 2013 13:23 UTC

Return-Path: <mirja.kuehlewind@ikr.uni-stuttgart.de>
X-Original-To: conex@ietfa.amsl.com
Delivered-To: conex@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 90B2E21F96D9 for <conex@ietfa.amsl.com>; Mon, 3 Jun 2013 06:23:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.298
X-Spam-Status: No, score=0.298 tagged_above=-999 required=5 tests=[AWL=-0.353, BAYES_50=0.001, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id VJTLbotXQHYO for <conex@ietfa.amsl.com>; Mon, 3 Jun 2013 06:23:46 -0700 (PDT)
Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de []) by ietfa.amsl.com (Postfix) with ESMTP id 6062821F95E9 for <conex@ietf.org>; Mon, 3 Jun 2013 06:23:43 -0700 (PDT)
Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c []) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id A246C601CA for <conex@ietf.org>; Mon, 3 Jun 2013 15:23:37 +0200 (CEST)
Received: from vpn-2-cl195 (vpn-2-cl195 []) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 9CB39601C9 for <conex@ietf.org>; Mon, 3 Jun 2013 15:23:37 +0200 (CEST)
From: Mirja =?iso-8859-1?q?K=FChlewind?= <mirja.kuehlewind@ikr.uni-stuttgart.de>
To: conex@ietf.org
Date: Mon, 3 Jun 2013 15:23:37 +0200
User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316)
MIME-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <201306031523.37193.mkuehle@ikr.uni-stuttgart.de>
Subject: [conex] 2) False positives of the audit
X-BeenThere: conex@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Congestion Exposure working group discussion list <conex.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/conex>, <mailto:conex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/conex>
List-Post: <mailto:conex@ietf.org>
List-Help: <mailto:conex-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/conex>, <mailto:conex-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Jun 2013 13:23:51 -0000


this question is directly related to the first one. If we have not done 
anything wrong at the sender but the audit still penalizes us because of 
wrong information at the audit, we need to detect this case at the sender and 
do something, e.g., as just proposed, send more credits.

My only guess right now, how to detect such a false positive of the audit at 
the sender is, that if we see congestion (loss or ECN) for more than one RTT 
eventhough we have reduces our sending rate it must be a false positive.

Thus in the worst case, we will see a large number of losses (upto all) 
induced by the audit. This will cause the sender to send further ConEx L 
marking and might lead to another throttling by the policer.
If the audit drops too less packets on the other hand, it is not a sufficient 
penalty and FEC might be able to compensate (at least for shorter 

Thus whenever there is a false positive by the audit, I currently would assume 
that this would strongly slow down or stop the transmission. But with the 
risk of loosing ConEx marked packets in the network and also not having 
sufficiently accurate ECN feedback, there will always be false positives.