Re: [ippm] Magnus Westerlund's Discuss on draft-ietf-ippm-capacity-metric-method-06: (with DISCUSS)

[[e-mail]]

Hi Magnus,

Thanks. My comments refer to the ramp up phase of the measurement only, an important aspect I forgot to mention.

The sender has a  congestion budget Buffer_max[ms]@R[x] based on the last sending rate R[x] confirmed by FT[x] without congestion, when it starts to send by R[x+1] . 
- It takes RTT + FT, before that rate is adapted as a minimum. 
- As the smallest optimistic waiting time, after st[x+1] + Buffer_max[ms], there's no more queue at the receiver's access (if there's no competing traffic). 

That would help to determine a function when to earliest start the next st[x+2]. A behaviour definition specifying how to react after FT + RTT + Tolerance without any feedback may be as follows: 
- Repeat after Timeout by sending another st at rate R[x+1]. 
- Timeout = max ( st[x+1] + T_secure *  Buffer_max[ms] , FT + RTT + Tolerance ) with T_secure being an integer. "Tolerance" [s] on the order of some 10 [ms], I'd think.

Design doesn't have to be exactly like that, this is about the concept. Len, Al, please contact me if I missed an important part of the implementation (or if I here suggest to slow down the measurement to eternal).

Regards,

Rudiger (stick with "u", if the "ue" puzzles you)





-----Ursprüngliche Nachricht-----
Von: Magnus Westerlund <[e-mail]> 
Gesendet: Freitag, 12. März 2021 14:11
An: Geib, Rüdiger <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Betreff: RE: Magnus Westerlund's Discuss on draft-ietf-ippm-capacity-metric-method-06: (with DISCUSS)

Hi Reudiger,


> -----Original Message-----
> From: [e-mail] <[e-mail]>
> Sent: den 11 mars 2021 17:32
> To: Magnus Westerlund <[e-mail]>
> Cc: [e-mail]; [e-mail]; draft-ietf-ippm-capacity-
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: AW: Magnus Westerlund's Discuss on draft-ietf-ippm-capacity-
> metric-method-06: (with DISCUSS)
>
> Hi Magnus,
>
> Before going to discuss details some questions:
>
> Would it help to insert text that person initiating test is required to
> parametrize an access bandwidth to be validated?
> I'm asking, as the intent of the draft might not be to capture a completely
> unknown access bandwidth (but I think it doesn't say so explicitely yet).

I think that would help significantly.

>
> Do some of your comments address a concern that a test creates to much
> congestion during one feedback interval FT?
> That may stem from the idea, that we've exactly reached access bandwidth
> AB during FT and badly congest the access during FT+1 (I don't deny that 
> this
> is possible).

Yes, what I am worried in some cases is the amount of overshoot the load 
algorithm can cause. And that is not just one FT interval. The regulation loop 
is somewhere between one RTT and RTT + FT long without feedback losses, and 
with losses it could be as long as RTT + m*FT where m is the number of 
feedback interval until one makes it in the feedback. Thus the congestion 
volume in a static system becomes (R[x+1]-R[x])*(RTT + m*FT) and where RTT 
+m*FT is capped by the longest non responsive interval. So have much data this 
represents, i.e. how badly one affect the on path with overload. So this is 
highly dependent on the parameters which is why I think this is so hard to 
evaluate.

>
> If that's your concern, would an approach to limit the maximum congestion
> created before FT+1 is reached being bound to a limit
> Buffer_max[ms]@AB[Bit/s] based on the last captured congestion free
> bandwidth AB during FT?
> As an example, Buffer_max = 0,05 s if AB < 1 Gbit/s (smaller Buffer_max
> values may be applicable at higher rates). This would result in a formula
> determining the sending behaviour during st, rather than a table.

I am not certain if I understand this correctly. Are you proposing to have a 
congestion window for the increase, or the full transmission, so that it will 
throttle if it doesn't get feedback in a timely way?

I think the main problem here is that one need to analyze the parameter space 
for the limiter that are proposed and what impact the parameters have. That 
has been part of my problem analyzing the updated text.

Cheers

Magnus Westerlund