On 3/22/07, Gerrit Renker <gerrit@xxxxxxxxxxxxxx> wrote:
[CCID 3]: Avoid accumulation of large send credit Problem: -------- Large backlogs of packets which can be sent immediately currently accumulate when (i) the application idles, or (ii) the application emits at a rate slower than the allowed rate X/s, or (iii) due to scheduling inaccuracy (resolution only up to HZ). The consequence is that a huge burst of packets can be sent immediately, which violates the allowed sending rate and can (worst case) choke the network. NB: Corresponding paragraph on send credits recently added to rfc3448bis Fix: ---- Avoid any backlog of sending time which is greater than one whole t_ipi. This permits the coarse-granularity bursts mentioned in [RFC 3448, 4.6], but disallows the disproportionally large bursts.
I think we should be going with greater than max(t_ipi, t_gran) as per discussion on IETF list and proposal by Sally Floyd http://www1.ietf.org/mail-archive/web/dccp/current/msg02281.html I do know that Gerrit has some reservations around the whole granularity of scheduling issue and I will try and address these at some point but Eddie/Sally seem to be siding around allowing packet bursts as per how we read RFC spec. Ian -- Web: http://wand.net.nz/~iam4 Blog: http://iansblog.jandi.co.nz WAND Network Research Group - To unsubscribe from this list: send the line "unsubscribe dccp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
