[prev in list] [next in list] [prev in thread] [next in thread] 

List:       dccp
Subject:    Re: [dccp] Packet size s on CCID3
From:       Gorry Fairhurst <gorry () erg ! abdn ! ac ! uk>
Date:       2006-09-26 12:19:47
Message-ID: 45191AE3.2020701 () erg ! abdn ! ac ! uk
[Download RAW message or body]

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).
-
To unsubscribe from this list: send the line "unsubscribe dccp" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]