Why I use a Mac, anno 2006 3721

when I started on hsdt project

one of the things that I soon realized that a lot of the protocols were in need of rate-based pacing NOT windowing. windowing had originally been a link-layer thing to provide a little bit of asyncronous overlap but avoid overring the receiving links buffer allocation. however, it soon got contorted into addressing all sorts of asyncronous behavior buttociated with other forms of congestion ... frequently totally unrelated to the number of pre-allocated buffers at the receiving link.

having done a whole lot with resource management and scheduling as an undergraduate ... and prone to translating things into rates ... it seemed trivially obvious that rate-based pacing was a requirement and that windowing was a very contorting and ill-suited construct for the tast.

the issue can come up in almost any environment with a "large" bandwidth*delay product (where "large" can be quite relative). I encountered it with satellites in the early 80s when the bandwidth was frequently 20-30 times that of a lot of terrestrial links ... and the delay was significantly larger. however, it cropped also in very high bandwidth fiber terrestrial connections as well as multi-hop networks.

some number of papers in the late 80s demonstrated that windowing was particularly ill-suited to large multi-hop networks. the actual objective is to be able to transmit packets w-o having to wait for full round-trip delay ... but possibly not transmit them continuously that they overwhelm the intermediate and end nodes. windows sort of have an buttumption that there is a uniform distribution between transmissions. However, there is actually nothing in basic windowing operations that create intervals between transmissions ... other than once you have fully transmitted up to the max. window size, you then have to wait until ACKs come back.

The actual problem is rate of transmission arrivals ... or another way of thinking about it is multiple back-to-back transmission arrivals. There are slow-start strategies that attempt to address spreading out the back-to-back transmissions. The problem is that windowing is a mismatched paradigm for the actual problem. For one thing, they found in large multi-hop networks ... there was frequently bursty traffic, asyncronous traffic flows, ACK batching, and ACK piggybacking. All of these tending to create long delays between the transmitting after the time that the last transmission occured "filling" the window ... and the arrival of ACKs that started to empty the window full condition. However, lots of things contributed to emptying a large number of windows in a burst ... which allows a large number of back-to-back transmissions to occur in a burst ... which then saturates intermediate and-or end nodes.

One way of doing rate-based pacing is to adjust the interval between transmissions. You are no longer directly concerned with the number of outstanding packets and-or the actual total end-to-end round-trip delay. The transmissions completely fill the path ... regardless of the round-trip delay and-or the bandwidth*delay product ... to the limit that the transmissions can be handled by intermediate and-or end nodes. In rate-based pacing there is no direct issue with the size of the channel or delay ... purely with how fast that the receivers can process the transmission.

At one point, I realized that a large number of platforms weren't using window strategy ... as a really poor subsbreastute for rate-based pacing ... not because it was thot to be a better approach ... but because many of the platforms had such dismall timer facilities where it was impossible to implement any reasonable pacing strategy.

misc. past rate-based pacing postings: