Rate Limit Period no longer fungible?

In 1.x, we had applied multiple rate limiting ratesets for different periods - eg. one set for 60s, one set for 10s. Is that no longer possible in the 2.0 middleware? Doesn't seem like you can set the period any more...

Example from before:

        traefik.frontend.rateLimit.extractorFunc: 'client.ip'
        traefik.frontend.rateLimit.rateSet.burst1m.period: 60s
        traefik.frontend.rateLimit.rateSet.burst1m.average: 2000
        traefik.frontend.rateLimit.rateSet.burst1m.burst: 4000
        traefik.frontend.rateLimit.rateSet.burst10s.period: 10s
        traefik.frontend.rateLimit.rateSet.burst10s.average: 300
        traefik.frontend.rateLimit.rateSet.burst10s.burst: 600

Hello,

the core of the rate limit has been rewritten.

The gritty details are that we're basically using https://godoc.org/golang.org/x/time/rate#Limiter with a Reservation.
And we give up on that reservation if it can't be satisfied under 1s/(2*Average).
This limit on the reservation is the somewhat arbitrary period that the doc is talking about.

there's no more period to be configured.

This is a severe loss of functionality. Will this be brought to par with what was there?

There is no loss: the behavior changed to be more stable and more predictable.

With the reservation system, you can do more and better even without period.

But how? How do I convert my thinking from what you had to what you have now? How would you implement now what I had above?

Can you please explain what you are trying to achieve? What is the scenario here, with respect to different sources, routers, etc?