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

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

 




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?)
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




[Index of Archives]     [Linux Kernel Development]     [Linux DCCP]     [IETF Annouce]     [Linux Networking]     [Git]     [Security]     [Linux Assembly]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [DDR & Rambus]

  Powered by Linux