Re: [tcpm] Updating Proportional Rate Reduction RFC6937 to PS

[Mirja Kuehlewind <[e-mail]>]

Hi Michael, hi Matt,

Frist I like to note that I support moving RFC6937 to PS and I'm happy to see that there is an additional heuristic to address "double drops". 

Years ago when we worked on RFC6937 in tcpm, I believe I observed a similar problem after slow start, where slow start will not only fill the queue but overshoot to double the cwnd. So when you "only" halve the cwnd as PRR does correctly, you end up will a full queue after recovery and you will see another congestion event soon after. Rate halving however would end up with only 1/4 of the cwnd after recovery and respectively empty the queue. However, in the end there was not much of a difference (regarding throughput and number of losses), only PRR would actually keep the queue slightly longer full... is this case also addressed by this heuristic?

Mirja



On 20.10.20, 08:11, "tcpm on behalf of Michael Welzl" <[e-mail] on behalf of [e-mail]> wrote:

    Hi again,

    You don't understand it because it doesn't make sense; I get it now, and I was just wrong, I'm sorry.
    I've recently been thinking too much about a paced, non-ack-clocked behavior, where things might indeed play out as I described, even with an overshoot of only one segment.

    With ACK clocking, as you said, that can't happen. In fact, I can see it become a problem only in one case: when the overshoot is so high that setting back the cwnd won't save you, even with ack clocking. But I think this translates exactly into "pipe < ssthresh", and this is the case that the heuristics cover - which, as you said, were designed to handle these double drops (*). So it all makes sense to me now, sorry for this excursion into the land on nonsense. Case closed, go home everyone, nothing to see here!  :-)

    Cheers,
    Michael
    --
    (*) In practice, I therefore think that these heuristics can play an important role after the very first slow start.



    > On 20 Oct 2020, at 07:25, Matt Mathis <[e-mail]> wrote:
    > 
    > I don't understand the situation you are thinking about.  If the bottleneck BW changes and it causes loss any loss, you would expect to see a whole RTT of periodic losses between the first detected loss, and the ACK from the first retransmission.  If inflight (aka pipe) is larger than ssthresh, PRR will always send less data than has left the network.  This is guaranteed by the
    > conservative self clock and the "proportional" part of the algorithm.  Yes it drains the queue slowly, and yes cross traffic can cause additional losses, but that is because the cross traffic is being too aggressive (e.g. the cross traffic has to still be increasing its instantaneous rate for some reason).
    > 
    > Thanks,
    > --MM--
    > The best way to predict the future is to create it.  - Alan Kay
    > 
    > We must not tolerate intolerance;
    >        however our response must be carefully measured: 
    >             too strong would be hypocritical and risks spiraling out of control;
    >             too weak risks being mistaken for tacit approval.
    > 
    > 
    > On Mon, Oct 19, 2020 at 2:47 PM Michael Welzl <[e-mail]> wrote:
    > Hi,
    > 
    > In line:
    > 
    > > On Oct 19, 2020, at 7:20 PM, Matt Mathis <[e-mail]> wrote:
    > > 
    > > The heuristic was designed to address the "double drops" that you noted.    Both RFC 6675 and PRR-SSRB can be too aggressive in situations where there are burst losses that cause the flight size to fall below ssthresh.  Sometimes these are ok, but they often cause lost retransmissions.  The new heuristic is to prevent these situation from persisting.
    > 
    > I get that, but what I’m concerned about is a case where pipe is *not* below ssthresh, so the heuristics don’t even apply. It’s enough to consider the “diagram" on page 7, where it’s clear that RFC 6675 takes a break from segment 4 to 11 but PRR (or rate-halving) doesn’t. This is fine when the new rate is smaller than the bottleneck’s capacity, but if it’s not, the queue should just overflow again, I believe.
    > 
    > (again, these are all more suspicions than anything else - I only have indications, from our own experiments and the paper I pointed to, nothing really clear that shows that this really happens; come to think of it, it actually wouldn’t be hard for me to run a check in our testbed… perhaps that would be better than making a fuss here about something that may turn out to be nothing. Then again, maybe it’s a good conversation to have anyway, just to see what the thinking around this type of concern is.)
    > 
    > 
    > > These situations are hard to reason about because they can not be caused by events that are modeled by simple queues.  The Flatch paper is about token bucket policers which cause huge losses when they run out of tokens -- all without significant queues.  Other potential events include bursty cross traffic from long RTT or non-responsive flows.
    > 
    > Ok, but that’s not the case I mean, mine is simpler (above). Even just a single packet loss would suffice for the situation I’m talking about.
    > 
    > 
    > > With packet conservation, a single flow can not cause self inflicted losses that last more than one RTT, and thus can't cause lost retransmissions.
    > 
    > Hmmmmmm….. I doubt this; I think the backoff factor and queue also play a role. The point is that the new cwnd may be too much, just like the old was too much.
    > 
    > 
    > >     If there are lost retransmissions something happened that is outside the scope a simple network model.
    > > 
    > > While I agree that 6675's half RTT of silence reduces queue pressure, the responsibility for that really belongs to congestion control, which should not be controlling against queue full.
    > 
    > I agree with the thought, but in IETF terms I think that a recovery mechanism in a PS RFC has to be compatible with RFC 5681 too.
    > 
    > 
    > >   The goal of PRR is to minimize the opportunities to lose the self clock by accurately controlling flightsize to the target set by the congestion control.
    > > 
    > > The heuristic also helps in the situation where there was a large step change in the available bandwidth, and the CC can not possibly estimate the the correct flightsize quickly enough. 
    > 
    > I understand; generally, I don’t doubt that there are many good aspects to PRR, and that it will work better than RFC 6675 in many cases. The half-RTT-of-nothing pattern is just odd.
    > So maybe what I’m worrying about is a corner case. But, as we talk about proceeding to PS, I think it deserves a thought.
    > 
    > Cheers,
    > Michael
    > 

    _______________________________________________
    tcpm mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/tcpm