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

[David Wagner <[e-mail]>]

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 



On Friday 18 October 2013 17:37:48 Matt Mathis wrote:
> 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 <
> [e-mail]> wrote:
> 
> > 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
> >
> >
> > On Friday 18 October 2013 16:56:31 Bob Briscoe wrote:
> > > 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
> > > >
> > > >On Wednesday 16 October 2013 19:52:29 Bob Briscoe wrote:
> > > > > 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
> > > > >
> > > > > _______________________________________________
> > > > > conex mailing list
> > > > > [e-mail]
> > > > > 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:
> > [e-mail]
> > > >phone: [phone]        fax: [phone]
> > > >-------------------------------------------------------------------
> > >
> > > ________________________________________________________________
> > > Bob Briscoe,                                                  BT
> > >
> > >
> >
> >
> > --
> > 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: [e-mail]
> > phone: [phone]        fax: [phone]
> > -------------------------------------------------------------------
> >
> 


-- 
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: [e-mail]
phone: [phone]        fax: [phone]
-------------------------------------------------------------------