Re: Packet size s on CCID3

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

 



Hello;  we may have finally got to the root of the confusion.

Section 5.3 of RFC 4342 gives two ways to calculate "s", 's=MSS' and average packet size.

Both choices remain valid.

HOWEVER, the implementation MUST apply its choice consistently. For example, the application MUST NOT use average packet size to calculate X_calc, and simultaneously use 's=MSS' to calculate t_ipi.

Does that help?


Arjuna Sathiaseelan wrote:
After a long discussion with Gerrit, I would just like to point out
two things that needs to be fixed in TFRC/CCID3:

1) Make it "explicit" to use a consistent "s" throughout the drafts/RFCs.
    - The reason why we see this as a problem is because of two things:
        *  The Initial rate calculation: X_inst = X = W_init/R =
min(4*MSS, max(2*MSS, 4380))/R, and then use t_ipi = s/X_inst. What is
s here? MSS or the actual/average packet size?

See above, but this is not really a problem:

- X_inst is always calculated using MSS, as the spec says.
- t_ipi is calculated using whatever the app is using for the packet size variable "s", as the spec says. This might be MSS.

>         * As pointed out in the earlier mails by Eddie, using a large
> "s" for X_calc and then using a small "s" for t_ipi.

Huh, did I say this? 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.)


2)Make it clear on what "s" should be. We personally feel "s" can just
be the average packet size since if the packet size is constant, then
average of "s" is constant and if "s" is varying then averaging seems
to be fine. We are still not able to decipher why we require MSS to be
used as "s". Maybe we are mere mortals :)

OK, one more time.

- The implementation MAY calculate 's' using a moving average of actual packet sizes over the last four loss intervals,
OR
- The implementation MAY set 's=MSS'.

Whichever choice is made must be applied consistently, i.e., wherever 's' appears.

OK?

Eddie


[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