Hi there Gerrit, I've been thinking a bit about this and can see what's happening here and with delays in general. There's a case here that I can't see the RFC covering and I'll send to the IETF list a follow up to this one.
It appears that in this case the sender can't keep up with the allowed transmit rate so the negative credit gets bigger and bigger. This is OK until we actually get some loss and then we won't be able to back off quickly. The other scenario that this causes a problem if we don't reset t_nom is where we have idle periods. If we go idle for 10 seconds then we could potentially send heaps at that point to catch t_nom up. This doesn't seem right. Ian On 16/01/07, Gerrit Renker <[EMAIL PROTECTED]> wrote:
Here is a log which I took after dropping the 3d patch which resets t_nom when tnom < t_now. It shows that the negative credit does not clear, hence all packets are sent in one huge burst. [ 75.646215] ccid3_hc_tx_update_x: X_prev=23743226, X_now=23728510, X_calc=0, X_recv=11864255 [ 75.646218] ccid3_update_send_interval: t_ipi=59, delta=29, s=1415, X=23728510 [ 75.646223] ccid3_hc_tx_packet_recv: client(f651c080), RTT=4498us (sample=5517us), s=1415, p=0, X_calc=0, X_recv=11864255, X=23728510 [ 75.646264] ccid3_hc_tx_send_packet: delay=-14235 [ 75.646314] ccid3_hc_tx_send_packet: delay=-14226 [ 75.646451] ccid3_hc_tx_send_packet: delay=-14304
-- 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
