<DIV>See within (--->)<BR><BR><B><I>Puddinhead Wilson <puddinghead_wilson007@yahoo.co.uk></I></B> wrote:
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">
<P>Hello Simpleton/all,<BR> <BR>I have some queries<BR><BR>Please follow the >><BR><BR><BR><BR><BR>A) Minimum throughput<BR>=======================<BR><BR>When you browse through tcp literature, you will<BR>usually come across<BR>the Bandwidth x Delay=Window formula. It has a very<BR>straightforward <BR>meaning: If you want to get a full utilization of the<BR>available bandwidth,<BR>you better have a window that is large enough to fill<BR>the RTT with packets.<BR><BR>Even a simpleton like myself knows this. But let us<BR>ask the question in <BR>reverse: How *low* a bandwidth can we pass through a<BR>line with a given, fixed,<BR>delay? Some simple thinking will show you than it is<BR>(almost) impossible to <BR>deliver less that a few MSS each RTT. Why? Because<BR>even during slow start, tcp<BR>sends a new packet once an ack is recieved.<BR><BR><BR>>> excellent point, I would appreciate if this list<BR>for one clarified the "MSS". Today we support jumbo<BR>frames etc.
Does this imply we increase the MSS<BR>propotional to the MTU?<BR><BR><BR><BR>What is the implication of the above? That in order to<BR>cause a tcp flow to use *less* than the<BR>physically available link, one must *increase* the<BR>RTT. Of course, this is exactly what shapers<BR>do, by buffering the data. alternatively one could<BR>buffer the acks ( and I think that "ack holding"<BR>schemes have been proposed in the literature), but<BR>that requires L3- L4 knowledge and treatment of <BR>piggybACKs.<BR><BR><BR>>> Shapers also provide something else. They let you<BR>differentiate services. Assume that one wants to<BR>really run a "converged network" which carries voice,<BR>video and data, one also needs the flexibility to have<BR>CBR. Shappers can do that.<BR>Eitherways, shappers or no shappers, if everything was<BR>"policers" or say, slotted/TDM access based, there<BR>would still always be a point in the network where one<BR>would have to "buffer", and that is the point
of<BR>ingress into the "policed" core. This specifically<BR>holds true for cases where we have say a 100Mbps LAN<BR>and a X<100Mbps WAN slotted access bandwidth in front.<BR><BR>----> Agreed, but one way to use shapers to differentiate, is the diffserve scheme. In diffserve, you don't allocate a shaper per *service* but per *class of service*. or in other words, you aggergate all services with the same CoS into the same shaper. This is done inside the network. At the edges, you can either shape, or police. If you police, you will run into the problems that I have described.<BR><BR>B) tcp timeout Phase<BR>========================<BR><BR>So what happens when you try to limit bandwidth below<BR>the MSS/RTT limit? A policer achieves this<BR>by discarding all packets that are non conforming, and<BR>this will cause the session to run in a<BR>burst-timeout-burst phase. Typical implementations set<BR>timeouts to as much as several hundred msec.<BR>In this phase ( that is ,
when ther required bandwidth<BR>is less that Const X MSS/RTT), the bandwidth <BR>can range from zero to [Policer Burst Size]/[Tcp<BR>Timeout] . This phase is not efficient, and causes<BR>huge<BR>bursts in the network. For timouts around 500 msec, a<BR>4 mb/s session ( which is not unreasonal on LANs<BR>and WANs) needs a policer burst of 512KB. since bursts<BR>tend to get translated into buffer sizes, we see<BR>that a single service eats up quite a large buffer<BR>size. The irony being, that in the timeout phase, the<BR>burst is not buffered, because if the burst was<BR>buffered, the RTT would increase, and we wouldn't have<BR>been<BR>in the Timoeout phase in the first place.<BR><BR><BR>>> agreed.<BR><BR>C) Partial window phase<BR>========================<BR><BR>A reasonable way to generate sub-physical line rates,<BR>( without adding to the RTT), is to cause <BR>the tcp to work at a window that is less that<BR>[physical Rate]x[RTT]. The frame pattern would be<BR>something like
M frames every RTT, with MxMSS/RTT ~<BR>[policed rate]. This is a much better behaviour<BR>than the timeout phase, and a good policer design<BR>should strive to reach this phase. As pointed out<BR>before, this phase cannot exist when the required rate<BR>is too low, or the RTT is too short.<BR><BR>>> Which is why TCP slow starts I presume (I believe<BR>the more "literate" on the list can correct me if I am<BR>wrong).<BR>----> I dont think that slow start was "designed" with policers in mind.<BR><BR>D) Stability of the partial window phase<BR>========================================<BR><BR>Eventually, because of slow start or congestion<BR>avoidence, the number of frames in the window M<BR>slowly creeps up, until the policer "realizes" that<BR>the policed rate has been passed, and the policer<BR>will discard a series of frames. If this is done<BR>delicately enough ( suppose using a RED like<BR>algorithm),<BR>Fast retransmission will take place and the session<BR>shall be
able to slow start its way back to the target<BR>of <BR>M frames per RTT. <BR><BR><BR>If the policing is too drastic, either an entire<BR>window of M packets will be discarded, or the<BR>fast-retransmit frame itself will be lost, and a<BR>timeout will occur. <BR>E) tcp defence lines and policers<BR>==================================<BR>tcp has three defence lines against congestion<BR>* self clocking<BR>* congestion window + slow start<BR>* retransmission timeout<BR>Not only do they protect the network, they also<BR>control the bandwidth that the application recieves. <BR>Policers neutralize completely the first line of<BR>defence, since they have no effect on the RTT ( or on<BR>the<BR>more subtle inter packet gap ). The only way that<BR>policers can indicate rate to the tcp layer is by<BR>packet discard. Tcp responds to packet discard by<BR>retransmission timeouts or fast retransmission, both<BR>are considered inefficient, but compared to the huge<BR>problems caused by timeouts,
the slight ineffciency<BR>caused by fast retransmission induced slow start, is<BR>minor. The estimation of timeouts based on averaged<BR>RTT<BR>statistics are totally irrelevant when the actual<BR>network performance is below 100msec, but the<BR>recommended<BR>tcp tick is 500msec.<BR><BR>>>Also consider the case of "how soon can that<BR>feedback" be given to the sliding window mechanism so<BR>as to detect that there was a "congestion". We are<BR>talking about a system where the propogation delay or<BR>duration of "feedback" is considerable compared to the<BR>rate at which the input comes/packets are transmitted.<BR><BR>F) What is the point?!<BR>======================<BR>The points are <BR>1- policers are much easier to build that shapers, so<BR>we should start to understand them.<BR><BR>>> Considering all the points you have made, it seems<BR>shappers should be the obvious choice. They need not<BR>be the "exact buffered" shappers as you mention them,<BR>but they could be
made such that:<BR>a. minimal buffering is needed at the end points.<BR>b. There is a way to differentiate CBR streams from<BR>non CBR streams</P>
<P>---> I suppose that giving a shaper per service is a possibility, but the complexity, compared to a shaper per CoS is prohibitive. Policers, on the other hand , are relatively simple to implement, and scaling is not a big issue. Shapers per CoS are enough to support differentiation, I'd imagine that policed CBR streams would go into a single high prioirty buffer, instead of having to select among many eligible CBR shapers . <BR><BR>2- acceptance tests are usually done with very short<BR>RTT times, so that the timeout phase is<BR>quite relevant.<BR>3- All these exponential smoothings and estimations of<BR>RTT RMS are useless if the smallest timeout<BR>is 300msec, and typical LAN's are less that 50msec.<BR><BR>>>Why would you say that?</P>
<P>---> my point is that afaik, the clock used to measure rtt and rttvar has a granularity of a few hundred msec ( except in very recent tcp implementations, where the cpu clock is used ). <BR><BR>4- alot of TCP improvements have been based around<BR>"LFN"'s but it may turn out that alot of the broad<BR>band networks are really "SFN"'s (Short Fat Networks).<BR><BR><BR>>>Let me put it this way, performance is always<BR>"relative". If you sit near an end point then it is<BR>SFN for you, else it is a LFN. Would that not be true?<BR>Eitherways, the idea is to get "more" out of an<BR>existing infrastructure, not to say "this<BR>infrastructure was not made for this".</P>
<P>---> I dont quite follow you here. Consider the following "practical" situation:</P>
<P>Your customer wants to bench mark your equipment. She hooks up 2 pc's back to back through your traffic managment box, and starts pinging /iperfing when the traffic managment is disabled. She measures a beautiful 700usec delay and a 100 Mb/s throughput ( say that its a 100bT FE interface). Now she tries to set the box to say 1Mb/s. There are two possibilites:</P>
<P>1) you are using a shaper, so that the delay jumps to about 12msec, and the bandwidth is fine.</P>
<P>2) you are using a policer. Every packet that gets transmitted has a 700usec delay, but there are alot of timeouts. Bandwidth is fine, because you have configured a large burst.</P>
<P>Both results need some explaining to the client. This is a fairly common situation.<BR><BR>G) The End<BR>============<BR>Thank you for you patience, comments are welcome.<BR><BR>Yet Another Simpleton<BR><BR><BR><BR><BR><BR><BR><BR><BR>____________________________________________________________<BR>Yahoo! Messenger - Communicate instantly..."Ping" <BR>your friends today! Download Messenger Now <BR>http://uk.messenger.yahoo.com/download/index.html</P></BLOCKQUOTE></DIV><p>
<hr size=1><font face=arial size=-1>Do you Yahoo!?<br><a href="http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=24311/*http://promo.yahoo.com/sbc/">SBC Yahoo!</a> - Internet access at a great low price.