Re: [conex] Expiration of credits

[John Leslie <[e-mail]>]

   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 <[e-mail]> 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.)

> 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.

   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...)

> 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.

   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...

--
John Leslie <[e-mail]>