Subject: [conex] Expiration of credits

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 26 Oct 2011 10:48:16 +0200

Hi list,

one more question, we need to answer for the TCP modifications draft:

In the draft we propose a way how to use the credits bits in Slow Start. We 
assume that the credits are valid for a couple of RTTs. But I assume that 
those credits should not be valid for ever, as otherwise I could just send 
credits whenever I have 'congestion volume tokens' available and not care 
about any conex markings later on. I believe we want to avoid this case. But 
I don't think that any kind of expiration of the credits bit is addressed yet 
(in the abstract mechanism draft)...?

Mirja

---

From: Toby Moncaster <[email-masked]>
Date: Wed, 26 Oct 2011 10:01:14 +0100

My view would be that the credits would remain valid for the duration of the connection, but there would be a cap on how much credit you could have (at most a few packets-worth).

Toby

On 26 Oct 2011, at 09:48, Mirja Kühlewind wrote:

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

---

From: John Leslie <[email-masked]>
Date: Wed, 26 Oct 2011 09:20:38 -0400

Mirja K?hlewind <[email-masked]> wrote:
> In the draft we propose a way how to use the credits bits in Slow Start.
> We assume that the credits are valid for a couple of RTTs.

   The credits, IMHO, are intended to cover for one RTT plus processing;
but nobody knows how long one RTT is...

> But I assume that those credits should not be valid for ever, as
> otherwise I could just send credits whenever I have 'congestion
> volume tokens' available and not care about any conex markings
> later on.

   I doubt that would prove useful.

   It is conceivable that someone somewhere might attempt to match
"credits" to congestion over a longer period; but I can't see this
would accomplish anything useful to the party counting them.

   A more likely practice would be to accrue an allowance up to a
maximum (which might be as low as a half-dozen packets worth or
might range up to thousands), and check for a "user" exhausting
that allowance. It is far too early, IMHO, to say what these rules
might be.

   Down the road a bit, your upstream may want to traffic-shape so
as to fit within a contractual allowance at each peering point. The
maximum you could accrue might be a function of traffic patterns
at these peering points.

> I believe we want to avoid this case. But I don't think that any
> kind of expiration of the credits bit is addressed yet (in the
> abstract mechanism draft)...?

   I don't believe that an "expiration" rule will prove helpful;
and I certainly don't believe we should try to define one at this
stage of the design.

   And I'm not sure we _could_ attach a useful definition to "valid"
here -- packets considered to be part of an "abusive" flow may get
dropped somewhere along the path, but that would be a function of
the "flow", not the individual "credits", and I can't imagine a
practical way to "expire" the "credits".

--
John Leslie <[email-masked]>

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 26 Oct 2011 18:08:25 +0200

Hi Toby,

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. If I increase the cwnd by 100 packet in 
one RTT I might want to send 100 credits (expect there are still some unused 
sitting in the audit device from a previous RTT).

Mirja

On Wednesday 26 October 2011 11:01:14 Toby Moncaster wrote:
> My view would be that the credits would remain valid for the duration of
> the connection, but there would be a cap on how much credit you could have
> (at most a few packets-worth).
>
> Toby
>
> > We assume that the credits are valid for a couple of RTTs. But I assume
> > that those credits should not be valid for ever, as otherwise I could
> > just send credits whenever I have 'congestion volume tokens' available
> > and not care about any conex markings later on. I believe we want to
> > avoid this case. But I don't think that any kind of expiration of the
> > credits bit is addressed yet (in the abstract mechanism draft)...?
> >
> > Mirja
> >
> >

-- 
-------------------------------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Institute of Communication Networks and Computer Engineering (IKR)
University of Stuttgart, Germany
Pfaffenwaldring 47, D-70569 Stuttgart

tel: +49(0)711/685-67973
email: [email-masked]
web: www.ikr.uni-stuttgart.de
-------------------------------------------------------------------

---

From: John Leslie <[email-masked]>
Date: Wed, 26 Oct 2011 12:33:26 -0400

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... :^}