That sounds perfect to me :). Also I hope Sally would note this in her
draft RFC3448-bis too. Thanks Eddie was considering my suggestions :).
Regards
Arjuna
On 10/4/06, Eddie Kohler <[EMAIL PROTECTED]> wrote:
>> - X_inst is always calculated using MSS, as the spec says.
>> - t_ipi is calculated
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 implementatio
- 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.
Do you mean when X_Inst = W_init/R?
OK, I was wrong AND misunderstood you. Let me try harder.
RFC 4342 has
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 MUST apply its choice consistently. For
example, the application MUST NOT use average packet size to calculate
X_calc, and simultaneou
Hi Eddie,
| (1) 's' may be treated in two ways, not three.
The specification should be modified to clearly reflect this (as per your
reply).
| (2) The variability is clearly implementable, just as a TCP stack can
| optionally support SACK.
With `variability' I referred to `s' meaning one
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 averag
Gerrit,
Gerrit Renker wrote:
| I don't think the RFCs are nearly as ambiguous as you claim. RFC 4342
| explicitly allows interpretations (2) 's' is an average and (3) 's = MSS'.
| (1) is not mentioned.
Section 5.3: "CCID 3 is intended for applications that use a fixed packet size,
and
Hi Ian,
Ian McDonald wrote:
Now change s to 300 bytes we get a Xcalc of 3128 and a t_ipi of 96
msecs. Put in ANY number for s and you will get the same t_ipi of 96
msecs.
This illustrates my point that CCID3 is a packet per second based
congestion control.
Now if we specify the s is 300 to the
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 calcul
Dear WG,
The IETF-67 meeting will include 2 hours of official agenda time for the
DCCP WG. Please do consider attending the meeting and bringing your
ideas, comments, issues and any new contributions to this meeting for
discussion. If you would like to offer something as a topic for the
Agend
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
| I don't think the RFCs are nearly as ambiguous as you claim. RFC 4342
| explicitly allows interpretations (2) 's' is an average and (3) 's = MSS'.
| (1) is not mentioned.
Section 5.3: "CCID 3 is intended for applications that use a fixed packet size,
and
that vary their sendi
12 matches
Mail list logo
