Subject: [conex] ConEx credit & audit: status update

From: Bob Briscoe <[email-masked]>
Date: Wed, 16 Oct 2013 18:52:29 +0100

ConEx chairs,

David Wagner, Mirja Kuehlewind & I have been meeting over the past 2 
days to sort out whether the approach to credit the w-g agreed is 
correct and feasible.

You may recall that last July we agreed at the working group meeting 
in Berlin to go with David Wagner's idea of requiring audit to check 
for a non-negative balance of (credit - (loss or ECN)) as well as 
(re-echo - (loss or ECN)), so the source has to effectively 'pay' 
twice for congestion, with credit and with re-echo.
(See draft-wagner-conex-credit-00 Section.3.3. "Credit As Congestion 
Surcharge")

The more I think about the idea, the more I like it - I'm grateful to 
David for thinking up this idea - it's solved an otherwise major 
problem. We all agree that there are still some niggles with it, 
which we will write up by updating David's draft (above).

But more importantly (if the relevant co-authors agree) we will 
reflect this change in thinking with the relevant normative text in:
         draft-ietf-conex-destopt and
         draft-ietf-conex-tcp-modifications.

For these expt track docs, we aim to issue new revisions before 
Monday's deadline, even there is no ConEx meeting planned for Vancouver.

We intend to write up a full (Informational) spec of audit and credit 
by revising
         draft-wagner-conex-credit-00 (we may use a new filename to 
include the word audit).

This will document all the potential attacks against ConEx and the 
way the audit function handles them. We'll need to build a new 
implementation to test it, then we can include reference pseudocode 
in the draft (all the ideas from the auditor in my PhD that Toby 
Moncaster implemented are just as applicable to these attacks, even 
with the change in the definition of credit).

Matt Mathis & I will also be making the few promised updates to
         conex-abstract-mech (Informational)
before Monday.

Bob

________________________________________________________________
Bob Briscoe,                                                  BT

---

From: David Wagner <[email-masked]>
Date: Fri, 18 Oct 2013 15:28:10 +0200

Hi *, 

we now are sure to understand that credit will not allow to completely avoid handling time estimations in the audit, but rather represents a risk for future congestion. Therefore, I think we should change the respective section in abstract-mech and we even could change the term to something more distinct like "congestion risk". 

I'd propose to keep the word credit to not cause (more) confusion but to make clear the meaning of that signal in the abstract-mech draft. I would then refer to that text in the audit draft. 

Agree? 

David 

On Wednesday 16 October 2013 19:52:29 Bob Briscoe wrote:
> _______________________________________________
> conex mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/conex
> 

-- 
Dipl.-Inf. David Wagner
Institute of Communication Networks and Computer Engineering (IKR)
University of Stuttgart
Pfaffenwaldring 47, D-70569 Stuttgart, Germany

web: www.ikr.uni-stuttgart.de   email: [email-masked]
phone: +49 711 685-67965        fax: +49 711 685-57965
-------------------------------------------------------------------

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 18 Oct 2013 15:56:31 +0100

David,

Dealing with credit wording in abstract-mech is 2nd on my todo list now.

I'm pretty sure the position is that abstract-mech is abstract. It 
doesn't define any details, only a thought framework. ConEx consists 
of a number of variables that can each be re-defined a little to 
allow others to be re-defined a little.

This new definition of credit is not cast in stone. It's an 
experimental approach the w-g is running with to see where it takes 
us. So the correct place to define the current precise meaning of 
ConEx concepts is in the experimental docs (destopt), not the 
informational overview (abstract-mech).

However, I won't completely agree or disagree with you until I've 
re-loaded state - I need to check what Matt was willing to agree to 
and consider how I could reword abstract-mech to include and hint at 
the new meaning of credit without over-constraining.

I'll be in touch with a final decision on abstract-meach wording 
before the end of Saturday (hopefully).

Bob

At 14:28 18/10/2013, David Wagner wrote:
>Hi *,
>
>we now are sure to understand that credit will not allow to 
>completely avoid handling time estimations in the audit, but rather 
>represents a risk for future congestion. Therefore, I think we 
>should change the respective section in abstract-mech and we even 
>could change the term to something more distinct like "congestion risk".
>
>I'd propose to keep the word credit to not cause (more) confusion 
>but to make clear the meaning of that signal in the abstract-mech 
>draft. I would then refer to that text in the audit draft.
>
>Agree?
>
>David
>

---

From: David Wagner <[email-masked]>
Date: Fri, 18 Oct 2013 17:09:26 +0200

Hi Bob, 

I agree, the abstract document should remain abstract. :-)
Anyway, right now, section 5.5.1 introduces credit as a signal used to avoid RTT-estimations at the audit (amongst other thoughts in this section). 
And I think we reached a state, at which we can exclude that this is possible to full extend.
I think you'll reflect that in your update and just intended to clarify on which basis I start with the audit doc and that I'll continue to use the term credit. 

Cheers,
David

---

From: Matt Mathis <[email-masked]>
Date: Fri, 18 Oct 2013 08:37:48 -0700

I missed something: What was the feedback on Abstract Mech?

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

Privacy matters!  We know from recent events that people are using our
services to speak in defiance of unjust governments.   We treat privacy and
security as matters of life and death, because for some users, they are.

On Fri, Oct 18, 2013 at 8:09 AM, David Wagner <
[email-masked]> wrote:

> Anyway, right now, section 5.5.1 introduces credit as a signal used to
> avoid RTT-estimations at the audit (amongst other thoughts in this section).
> I think you'll reflect that in your update and just intended to clarify on
> which basis I start with the audit doc and that I'll continue to use the
> term credit.
>
> Cheers,
> David
>
>

---

From: David Wagner <[email-masked]>
Date: Fri, 18 Oct 2013 18:12:06 +0200

Hi Matt, 

it only regards the text on credit. Right now, sec 5.5.1. says
"However, the audit function cannot be expected to wait for a round trip to check that one signal balances the other, because that requires excessive state and the auditor cannot easily determine the RTT of each flow. ... The transport signals sufficient credit in advance to cover congestion expected during its feedback delay. Then, the audit function does not need to make allowance for round trip delays that it cannot quantify. "

We found that credit does not help us from comparing current ConEx signals with ealier observed congestion signals (loss/ECE) at (now - RTT_max), maybe see my Berlin slides, slide 10. 
http://www.ietf.org/proceedings/87/slides/slides-87-conex-2.pdf
But we deem there is still a benefit in having a separate signal for yet-to-come congestion or congestion risk, e.g. allowing to police on the aggressiveness of slow starting flows. 

Therefore, I think this section needs a revision, concerning the motivation for the credit signal. 

David