<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 4 May 2015, at 11:28, Jonathan Morton <<a href="mailto:chromatix99@gmail.com">chromatix99@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><p dir="ltr">Generally, the minimum observed delay will correspond to the case when both inbound and outbound queues are empty throughout the path. This delay should correspond to basic propagation and forwarding delays, which can't be reduced further without altering some aspect of the network.</p><div><br></div></blockquote><div><br></div><div>Yep, that corresponds to (∆Q|G + ∆Q|S(min packet size)) - note that the composition/de-composition only work on the individual bases - i.e need to deal with the delay in terms of ∆Q|G seperately. We call the ∆Q|G and ∆Q|S the "structural delay" - as you point out needs change in some aspects of the network elements/their arrangement.</div><br><blockquote type="cite"><p dir="ltr">Higher observed delays than this will tend to correspond to one or both of the buffers at the bottleneck being persistently filled. </p></blockquote><div>the ∆Q|V (which can be established by measuring the delay and subtracting the (∆Q|G + ∆Q|S(packet size)) can measure this as an instantaneous value (not just at a persistent filing) - we've got measurements that show queues filling and emptying .</div><div><br></div><br><blockquote type="cite"><p dir="ltr">To work out which one, you'll need to estimate the network load in each direction. This is of course easiest if you can see all or most of the traffic passing the bottleneck link, or if you yourself are participating in that load, but it's probably possible in some other situations if you get creative.</p><div><br></div></blockquote><div><br></div>To estimate the contention for the common resource you need more than the load - you need the traffic pattern as well <br><blockquote type="cite"><p dir="ltr">To determine that bloat is NOT present, you need to observe delays that are close to the baseline unloaded condition, while also being fairly sure that the bottleneck link is saturated in the relevant direction.</p><div><br></div></blockquote><div><br></div>Noting that, delay and loss is, of course, a natural consequence of having a shared medium and that (sorry for being a bit contentious) - bloat is a subjective not objective term as<br><blockquote type="cite"><p dir="ltr">The most reliable indication of link saturation is to observe ECN marked packets, which will only normally be produced by an AQM algorithm signalling link congestion (where both endpoints of the flow have negotiated ECN support). A slightly less reliable indication of saturation is to observe lost packets, either via retransmission or ack patterns, especially if they occur in bursts or at remarkably regular intervals.</p><p dir="ltr"> - Jonathan Morton<br>
</p>
</blockquote></div><br></body></html>