[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [dccp] Packet size s on CCID3 (sudden changes in s)



On 10/5/06, Gorry Fairhurst <gorry at erg.abdn.ac.uk> 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