On 10/5/06, Gorry Fairhurst <gorry@xxxxxxxxxxxxxx> wrote:
Eddie said: <snip> > No valid implementation would use a large "s" for X_calc and > a small "s" for t_ipi. They are the same variable and must > take the same value in both calculations. (If the app changes > "s" between feedback packets, then maybe the cached X_calc > used a different value of "s" than t_ipi; is this what > you're worried about? But that seems like such a corner > case, I'd say the implementer can do whatever they want > -- either recalculate X_calc or use the old one until > the next feedback packet.) Things look clear if packets are of size s. But, as you say, now what happens when your application sends some (many) packets of size s and then increases the size: 160B...160B...160B...1460B...1460B...1460B... It doesn't seem quite right to me, that it can be allowed to send such a step-function in throughput (a large PMTU would reveal a larger problem). Should the sender recalculate t_ipi? (Is it practical?)
It should always keep track of t_ipi due to changing loss/rtt. But changing s doesn't alter t_ipi.
Or at least, can senders be told to work out that's it has just send "n" bytes in the period and this will exceed rate X and then stop sending, rather than continue to do this? Gorry
If s changes then X changes with it but t_ipi doesn't when you do the maths. Ian -- Ian McDonald Web: http://wand.net.nz/~iam4 Blog: http://imcdnzl.blogspot.com WAND Network Research Group Department of Computer Science University of Waikato New Zealand
