Re: [PATCH 2/25]: Avoid accumulation of large send credit

[Gerrit Renker <gerrit@erg.abdn.ac.uk>]

[not cc:ed to dccp@ietf]

There are some interesting points here, but please consider the other message
also. From an implementation point of view and in the current absence of a
normative or majority-supported view on how to deal with accumulation of send
credits which do in fact arise, I think it is safer and better to for the moment
stick with the default of one t_ipi as maximum current credit.

Quoting Ian McDonald:
|  Do we need to do some sanity checks on the rtt and adapt based on
|  that? I don't actually have the answers yet as just started thinking
|  about this and thought worthwhile kicking off a discussion as a real
|  implementation issue for CCID3 in Linux.
This sounds to me like the oscillation prevention mechanism from RFC 3448, which 
is expressly meant for networks with low statistical multiplexing (e.g. LANs). 

I have it in the pipeline but didn't want to submit until the present patches are
through, since it requires to change the computation of X, for which I would like
to have a review and decision first.