In https://tools.ietf.org/html/draft-ietf-aqm-pie-00#section-5.3,
It appears that burst_allowance is intended to allow a certain amount of traffic to get queued before the algorithm kicks in. (Because the algorithm isn't always running; it gets turned off when the queue gets near empty.) However, burst_allowance isn't decremented according to packet arrival, rather it is decremented each update period. So whether 100 bytes or 1M bytes pass through, burst_allowance is decremented at the same rate. Doesn't this seem wrong to not account for the quantity that is enqueued? As for the wording itself, "The burst allowance, noted by burst_allowance, is initialized to max_burst. As long as burst_allowance is above zero, an incoming packet will be enqueued bypassing the random drop process. During each update instance, the value of burst_allowance is decremented by the update period, Tupdate. When the congestion goes away, defined by us as p equals to 0 and both the current and previous samples of estimated delay are less than target_del, we reset burst_allowance to max_burst." It says that burst_allowance is to be decremented "during each update instance". Does an "update instance" correspond to a "measurement cycle"? Can this be made more precise? (I couldn't find "update instance" mentioned elsewhere.) >From the pseudo-code, it appears that it is decremented every 16ms; it only >gets set to BURST_ALLOWANCE at the transition from INACTIVE-->ACTIVE. (In Pseudo-code, I think BURST_ALLOWANCE means max_burst and burst_count means burst_allowance.) David Dolson Senior Software Architect, Sandvine Inc.
_______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
