Re: [dccp] Packet size s on CCID3

[Gorry Fairhurst <gorry@erg.abdn.ac.uk>]

Eddie Kohler wrote:

>> It is actually the opposite of what you say here. If you do the maths
>> and set s large then you can send more packets per second than what
>> you should be able to.
> 
> 
> While this is true, note that the draft explicitly allows 
> implementations to use the maximum segment size (i.e. the largest value 
> possible) for s!  So we are not THAT concerned about this kind of lying.
> 
> The bad case would be using one value of "s" to calculate "X", and then 
> using a DIFFERENT value of "s" to calculate the packet rate from "X".  
> As long as the same value of "s" is used to calculate "X" and to 
> calculate the packet rate from "X", the "s"s cancel out, as Ian points 
> out.  For mostly-fixed-size applications, no problem; the network will 
> provide whatever feedback is appropriate.
> 
> Why do we have "s" at all?  "s" helps account for applications that vary 
> their packet size over the long term.  E.g., 20 RTT of packet size X, 
> alternating with 20 RTT of packet size 3X.  We do not have simulations 
> demonstrating what affect an incorrect "s" value would have in such a 
> situation.  It would be interesting to see some data.
> 
> As Sally points out as well, the draft explicitly allows implementations 
> to cancel out the "s" (by assuming s=MSS), calculating rates in packets 
> per second only.
> 
> Eddie
> 
> 

That is consistent with my understanding.]

Thanks,

Gorry

P.S. I'm going through the TFRC-SP I-D in detail just now (with my WG 
Chair hat on).