Re: A few comments on LINK version 11
Aaron Falk <[email protected]> Wed, 12 Jun 2002 10:44:17 -0700
| Newsgroups | gmane.ietf.pilc |
|---|---|
| Message-ID | <[email protected]> |
> > 7 Bandwidth on Demand (BoD) Subnets > > Long delay BoD subnets pose problems similar to connection oriented > networks in anticipating traffic. While connection oriented subnets > hold idle channels open expecting new data to arrive, BoD subnets > request channel access based on buffer occupancy (or expected buffer > occupancy) on the sending port. Poor performance will likely result > if the sender does not anticipate additional traffic arriving at that > > I'm confused here. Is this sentence saying "Poor performance will likely > resuly if the sending host does not queue additional outgoing traffic > while the sender is waiting for its transmission request to be granted"? > If so, I agree. If not, can we talk? I may not disagree, I just don't > understand the point being made. The point is that if you always wait until packets arrive before requesting access to the channel, you'll get lousy performance. If you're smart you use some sort of heuristics to anticipate whether you'll need the channel in the future. Of course, being too agressive about grabbing channel bandwidth is a bad idea too (it degenerates into a circuit system). > > port during the time it takes to grant a transmission request. It is > recommended that the algorithm have the capability to extend a hold > on the channel for data that has arrived after the original request > was generated (this may done by piggybacking new requests on user > data). > > There are a wide variety of BoD protocols available. However, there > has been relatively little comprehensive research on the interactions > between the BoD mechanisms and Internet protocol performance. > Research on some specific mechanisms is available (e.g., [AR02]). > One item that has been studied is TCP's retransmission timer [KY02]. > BoD systems can cause spurious timeouts when adjusting from a > relatively high data rate to a relatively low data rate. In this > case, TCP's transmitted data takes longer to get through the network > than predicted by the retransmission timeout (RTO) and therefore the > TCP sender is prone to resending a segment prematurely. > > Could we also include the observation that delays to acquire a shared > control channel may also be reflected as sudden and unpredictable > "spikes" in apparent round-trip times, making RTO values "spike" > unpredictably as well? I'm trying to say that it's not just the change in > available bandwidth, but delays encountered while changing available > bandwidth as well... It's a valid point but not applicable to BoD algorithms. There are a lot of different algorithms for BoD. Not all of them use a control channel. Of those that do, they don't have bandwidth variations based on control traffic (i.e., fixed bw control channels). Just like not all of them have bandwidth oscillation. I think this section should remain as broad as possible. Otherwise, we could probably turn this doc into a book on possible issues associated with BoD. There are so many variables, it's hard to make useful broad statements other than "tread carefully". --aaron _______________________________________________ pilc mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pilc http://www.ietf.org/html.charters/pilc-charter.html http://pilc.grc.nasa.gov/