[conex] 3) Incentive to send right markings

Mirja K├╝hlewind <mirja.kuehlewind@ikr.uni-stuttgart.de> Mon, 03 June 2013 13:39 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF60221F991E for <conex@ietfa.amsl.com>; Mon, 3 Jun 2013 06:39:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.416
X-Spam-Level:
X-Spam-Status: No, score=0.416 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_50=0.001, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kAultAMOaTDx for <conex@ietfa.amsl.com>; Mon, 3 Jun 2013 06:39:03 -0700 (PDT)
Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id BEF1421F9929 for <conex@ietf.org>; Mon, 3 Jun 2013 06:39:03 -0700 (PDT)
Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 2AEE7601CC for <conex@ietf.org>; Mon, 3 Jun 2013 15:39:02 +0200 (CEST)
Received: from vpn-2-cl195 (vpn-2-cl195 [10.41.21.195]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 2801B601CB for <conex@ietf.org>; Mon, 3 Jun 2013 15:39:02 +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:39:01 +0200
User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316)
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <201306031539.01763.mkuehle@ikr.uni-stuttgart.de>
Subject: [conex] 3) Incentive to send right markings
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:39:09 -0000

Hi,

as long as the audit function counts credits the same way as it does count L/E 
marks, there is no incentive for a ConEx sender to send the right marking at 
the right time. And note, the goal of ConEx is to expose the current 
congestion level; thus L/E marks should be send as soon as the congestion has 
occurred and not earlier or not too late.

More specifically the problem is, that a TCP sender has to send a large number 
of credits during Slow Start. Thus as long as the total number of losses + CE 
markings is smaller than the number of send credits, there is no incentive to 
send any L/E ConEx marks.

Another case is if a token-bucket policer is used, the sender could simply 
send ConEx marking whenever the bucket would overflow (even though there has 
been not congestion).

We can limit the number of L/E (that can be accounted at the audit) to at max 
to number of actually seen losses and CE marks. But we cannot do something 
like this for the credits as the credits should be send before the congestion 
occurs.

I would proposed to give the credits a slight different meaning. Instead of 
having the credits forever sitting in the audit, they should be 'used' 
whenever congestion occurs. Thus as long as the L/E marks have not been sent 
yet and thus the audit is negative (not regarding the credits), the number of 
credits should be reduced somehow. We are currently still thinking about the 
details on this. I believe this would not solve the problems completely, but 
would help a lot. Any feedback and thoughts on this are very welcome!

Mirja