Subject: Re: [conex] Expiration of credits

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 2 Nov 2011 18:51:55 +0100

Hi,

one more question:

If I send a large number of credits in Slow Start, lets say 50, and than have 
a quite moderate TCP like Reno with drop tail. That means I usually see only 
on loss everytime my cwnd exceeds the link capacity. Lets say my max cwnd is 
100 the i reduce to 50 after a loss and it takes another 50 RTT until I see 
the next loss.

That means it take 50*50=2500 RTTs or 1500*50*50=3.75MByte until my credits 
are gone even if I don't send any further ConEx markings. Why should I send 
any real ConEx marking in this situation (and pay twice)?

But with ConEx we actually would like to have the real ConEx signal because 
only this reveals the current congestion level on the link!

Mirja

On Wednesday 26 October 2011 18:33:26 John Leslie wrote:
> Mirja Kuehlewind <[email-masked]> wrote:
> > I guess a cap is even more complicated. An expiration would somehow
> > depend on RTT but the num of credit you want to send (at once)
> > depend on the congestion control mechanism in the endsystem.
>
>    IMHO you should never depend upon a credit lasting more than one
> RTT.
>
>    That said, credits are intended for start-up -- and in many cases
> currently, you will need more than one RTT to infer that a packet
> was dropped (because ECN marking wasn't enabled at the bottleneck).
> There may be cases where you should decide whether to issue additional
> credits while waiting for a timeout -- and there are certainly cases
> where you _don't_ want to issue such additional credits.
>
> > If I increase the cwnd by 100 packet in one RTT I might want to
> > send 100 credits
>
>    I cannot imagine such a case. Credits need never exceed the greatest
> plausible loss. I cannot imagine increasing cwnd by 100 when I expect
> 100% packet loss.
>
>    IMHO, credits are not generally appropriate for any situation where
> you are increasing cwnd -- but I'm sure _someone_ will find a case
> where it would help... :^}
>
> --
> John Leslie <[email-masked]>

---

From: Matt Mathis <[email-masked]>
Date: Wed, 2 Nov 2011 11:37:52 -0700

So there are some problems here.  In a strictly conservative model you need
to have credit for every packet in flight because the network can dump/mark
(nearly) an entire window in a single event, for example due to
somebody else's  slowstart, re routing onto a slow link, etc.  In fact the
normal case for ending slow starting into a drop tail queue is expected to
cause 30-50% losses.  An auditor that treats these cases as serious
violations is likely to be viewed as broken and a non-starter, because TCP
or other protocols can not prevent these events, no matter how smart they
are.   Note that since the network triggered events (i.e. not slowstart)
can happen at any point during a long running connection, the credit memory
from the initial slowstart has to be "forever".

If the audit function is designed with the understanding that it is
intrinsically statistical: subject to false events and having a measured
response to possible violations, then lower credit thresholds and levels
make sense.

But you are correct in your observation that you have to build a large
credit to do slowstart(*) without a audit violation, and then to be TCP
friendly, the steady state marking/loss probability has to
be proportional to 1/(window^2), which is potentially infinitesimal by
comparison.  This is really a bug in the current "TCP friendly" paradigm
that can not be fixed by ConEx. I predict it will change in time, ConEx or
not.

The simple answer is that this problem is scale dependent, and
in those parts of the network where the fair share window size is small
(say under 20), chances are good that reasonable heuristics (including
decaying credits) will do well enough for auditing.    In the long run we
have to ditch AIMD congestion control, but that is way out of scope for
ConEx.

(*) Or whatever algorithm you use to prime the network without any
knowledge about its capabilities or state.

I hope this helps,
--MM--
The best way to predict the future is to create it.  - Alan Kay

On Wed, Nov 2, 2011 at 10:51 AM, Mirja Kühlewind <
[email-masked]> wrote:

> _______________________________________________
> conex mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/conex
>

---

From: John Leslie <[email-masked]>
Date: Wed, 2 Nov 2011 17:34:44 -0400

Matt makes several good points here. I mostly want to add that in the
RealWorld, the node where congestion occurs is unlikely to be able to
reliably differentiate which flow has built up a credit.

Matt Mathis <[email-masked]> wrote:
> 
> So there are some problems here. In a strictly conservative model you
> need to have credit for every packet in flight because the network can
> dump/mark (nearly) an entire window in a single event, for example due
> to somebody else's  slowstart, re routing onto a slow link, etc.

   We should be careful that we don't call such a rare event a ConEx
"violation". (OK, so it's not as "rare" as all that...)

   The way I see it, it's important to build up at least one credit for
slow-start, but that in the ordinary case you should be happy to get a
single ECN congestion-experienced mark and back off in one RTT -- if
the rest of your packets in flight get dropped, that's OK.

   OTOH, some uses might be paranoid about dropped packets and want a
larger credit built up -- if they had reason to believe "credit" packets
would get through with ECN marks. (I'm not sure it's in-scope to discuss
why they might believe that.)

> In fact the normal case for ending slow starting into a drop tail
> queue is expected to cause 30-50% losses.

   Cite?

   (I do expect fairly nasty drop rates in that case -- and I agree
it's plausible for startup traffic to an empty link.)

   I think the conventional wisdom is that one halving the rate is
sufficient; and that drop-tail will drop that many packets quite
regardless of ECN or ConEx marking.

> An auditor that treats these cases as serious violations is likely
> to be viewed as broken and a non-starter, because TCP or other
> protocols can not prevent these events, no matter how smart they
> are.

   A question we probably should address is whether it makes any sense
to consider a single ConEx mark, followed by dozens of packet drops,
to be a "violation". IMHO, it shouldn't be.

> Note that since the network triggered events (i.e. not slowstart)
> can happen at any point during a long running connection, the credit
> memory from the initial slowstart has to be "forever".

   s/has to be/would have to be/

   (I strongly believe we can't implement "forever" in the wild.)

> intrinsically statistical: subject to false events and having a
> measured response to possible violations, then lower credit
> thresholds and levels make sense.

   Agreed.

   (And I feel stronly that we must define it to be that way.)

> But you are correct in your observation that you have to build a
> large credit to do slowstart(*) without a audit violation, and
> then to be TCP friendly, the steady state marking/loss probability
> has to be proportional to 1/(window^2), which is potentially
> infinitesimal by comparison.

   Agreed.

> This is really a bug in the current "TCP friendly" paradigm that
> can not be fixed by ConEx. I predict it will change in time, ConEx
> or not.

   (I wish I were as confident...)

> in those parts of the network where the fair share window size is
> small (say under 20), chances are good that reasonable heuristics
> (including decaying credits) will do well enough for auditing.

   I doubt that will be true for even the average total-path in
today's Internet. Nor do I believe the situation will improve by
itself. :^(

> In the long run we have to ditch AIMD congestion control, but that
> is way out of scope for ConEx.

   Agreed, it's out of scope.

   However, I believe that sufficient ConEx deployment will make
it more acceptable to use alternatives to AIMD...