On 3/22/07, Gerrit Renker <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
