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;
On 10/5/06, Gorry Fairhurst [EMAIL PROTECTED] 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
Hi Ian,
what you prove is right, you there is no contradiction, just confusion due
to the numerical example, cf. inline.
Quoting Ian McDonald:
| I disagree with this reading of the RFC. The RFC explicitly allows the
sender
| to calculate X as if every packet had size 's = MSS'. As usual,
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
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
Maybe we should rename the variable s to the nominal packet size instead
of the packet size.
Eddie
Arjuna Sathiaseelan wrote:
Dear Eddie,
Thanks for your reply :). Please see inline:
Hello; we may have finally got to the root of the confusion.
Yes :)
HOWEVER, the implementation
There are a couple issues with the packet size.
This mail will list my understanding of those issues. It has no solutions,
for that there will be another mail.
One thing we have had to consider is that different congestion points in the
network might have different limitations.
