Re: [conex] WGLC for draft-ietf-conex-abstract-mech-06.txt

Ingemar Johansson S <> Wed, 21 November 2012 19:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C118321F8447 for <>; Wed, 21 Nov 2012 11:01:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.099
X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HiJ+8JXySQ9n for <>; Wed, 21 Nov 2012 11:01:14 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 44D8621F8446 for <>; Wed, 21 Nov 2012 11:01:14 -0800 (PST)
X-AuditID: c1b4fb2d-b7f1e6d000002d2c-a3-50ad24f95515
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 25.0F.11564.9F42DA05; Wed, 21 Nov 2012 20:01:13 +0100 (CET)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Wed, 21 Nov 2012 20:01:12 +0100
Received: from ([]) by ([]) with mapi id 14.02.0318.001; Wed, 21 Nov 2012 20:01:12 +0100
From: Ingemar Johansson S <>
To: John Leslie <>
Thread-Topic: [conex] WGLC for draft-ietf-conex-abstract-mech-06.txt
Thread-Index: AQHNx1njVg+tGahsb06Ne07rnDfUVZf0Q9ZwgAAIcgCAAFF3kA==
Date: Wed, 21 Nov 2012 19:01:11 +0000
Message-ID: <>
References: <> <> <> <> <20121121143830.GD28297@verdi>
In-Reply-To: <20121121143830.GD28297@verdi>
Accept-Language: sv-SE, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyM+Jvje5PlbUBBlc3iVocuvaT0eL9hfOM DkweS5b8ZPI4NvcwcwBTFJdNSmpOZllqkb5dAlfGlmtHWQruClfcn5/RwPiCv4uRg0NCwESi 94lVFyMnkCkmceHeerYuRi4OIYGTjBKX7u5ihXB2Mkp03u1nh3CWMEpMPbuAFaSFTcBGYuWh 74wgtoiAnMSvsw/AbGYBVYl9j2axgNjCAs4S20+eYYWocZGYevMfK8hmEQEnialXBEDCLEDl y78tZwexeQW8Jc5OO88CsWsdk8S+aR/YQBKcAtoSi27+ApvPKCArcf/7PRaIXeISt57MZ4J4 QUBiyZ7zzBC2qMTLx/9YIWxFiY+v9kHdpiOxYPcnNghbW2LZwtfMEIsFJU7OfAI2U0hAV2L9 jqvsExglZiFZMQtJ+ywk7bOQtC9gZFnFyJ6bmJmTXm64iREYUwe3/NbdwXjqnMghRmkOFiVx Xq6k/f5CAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGIsLDgtnyYnuYVfUOj730kwPO++T3X26 K9wOuSROWrAw659Qd5z8XkOuT9ec3MLUrhY5KyYfqStaHKEblStU96U2ZNX37F2rJ6w5MuXh VsstHGc2Tdd4KVhyJzRwU5q5ZGJ2dX6QuG7P03sWCg9WTyu4Y+osWG299Pmk5M6s5UZhk5Yo rBA9pMRSnJFoqMVcVJwIAA7Ejqx3AgAA
Cc: "" <>
Subject: Re: [conex] WGLC for draft-ietf-conex-abstract-mech-06.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Congestion Exposure working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 21 Nov 2012 19:01:15 -0000


I believe that it should be possible to write up a general statement without any additonal 3GPP soup. 
Such a statement would be like "when an existing flow is moved for instance due to a radio base station handover, any new auditor state that is created as a result of this should be pre loaded with the credit marks from...." my skills in english language fails me here, sorry.. please revise as needed.


-----Original Message-----
From: John Leslie [] 
Sent: den 21 november 2012 15:39
To: Ingemar Johansson S
Subject: Re: [conex] WGLC for draft-ietf-conex-abstract-mech-06.txt

Ingemar Johansson S <> wrote:
> One comment though on page 5, 3rd para.
> " the flow-state required for audit creates itself as it detects new  
> flows.  Therefore a flow will not fail if it is re-routed away from  
> the audit box currently holding its flow-state. "
> If I map ConEx to a 3GPP LTE use case, the audit functions are best 
> placed in the eNodeB. When a new (long lived) flow is created it is 
> preferably preloaded with credit marks which are stored in the auditor 
> in the eNodeB which the terminal is "connected" to. When the terminal 
> hands over to another eNodeB the credit marks will be lost. This means 
> that the ConEx markings will in this case be at least one RTT behind 
> with a higher risk of false positives in the auditor in the new eNodeB 
> To avoid this the credit marks would need to be forwarded to the new 
> eNodeB via e.g the X2 interface.
> So my question is, is it needed to add a statement that mentions this ?

   I think it would be very helpful to work out wording for this -- in network-layer terminology. (Long-Term-Evolution alphabet-soup is beyond what we should expect of our readers.)

   If I understand you (not a sure thing, alas!), you're saying that when a network-layer node has reason to know the path forwarding is changing, it should insert extra ConEx Credit marks in order that an Audit function in the new forwarding path not interpret congestion it observes in the presence of ConEx-Not-Marked signals to be understatement of congestion, which calls for "some sanction" to be applied.

   (From Section 5.5.1, "if the balance ever goes negative, the audit function can immediately start punishing a flow, without any grace

John Leslie <>