On 06/27/2011 05:11 AM, Thomas Graf wrote: > On Fri, Jun 24, 2011 at 11:21:11AM -0400, Vladislav Yasevich wrote: >> We, instead of trying to underestimate the window size, try to over-estimate it. >> Almost every implementation has some kind of overhead and we don't know how >> that overhead will impact the window. As such we try to temporarily account for this >> overhead. > > I looked into this some more and it turns out that adding per-packet > overhead is difficult because when we mark chunks for retransmissions > we have to add its data size to the peer rwnd again but we have no > idea how many packets were used for the initial transmission. Therefore > if we add an overhead, we can only do so per chunk. > Good point. >> If we treat the window as strictly available data, then we may end up sending a lot more traffic >> then the window can take thus causing us to enter 0 window probe and potential retransmission >> issues that will trigger congestion control. >> We'd like to avoid that so we put some overhead into our computations. It may not be ideal >> since we do this on a per-chunk basis. It could probably be done on per-packet basis instead. >> This way, we'll essentially over-estimate but under-subscribe our current view of the peers >> window. So in one shot, we are not going to over-fill it and will get an updated view next >> time the SACK arrives. > > What kind of configuration showed this behaviour? Did you observe that > issue with Linux peers? Yes, this was observed with linux peers. > If a peer announces an a_rwnd which it cannot > handle then that is a implementation bug of the receiver and not of the > sender. > > We won't go into zero window probe mode that easily, remember it's only > one packet allowed in flight while rwnd is 0. We always take into > account outstanding bytes when updating rwnd with a_rwnd so our view of > the peer's rwnd is very accurate. > > In fact the RFC clearly states when and how to update the peer rwnd: > > B) Any time a DATA chunk is transmitted (or retransmitted) to a peer, > the endpoint subtracts the data size of the chunk from the rwnd of > that peer. > > I would like to try and reproduce the behaviour you have observed and > fix it without cutting our ability to produce pmtu maxed packets with > small data chunks. > This was easily reproducible with sctp_darn tool using 1 byte payload. This was a while ago, and I dont' know if anyone has tried it recently. -vlad -- To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
