Comments on RFC3448bis -05

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

 




As a part of my WG Chair read-through, I have some more comments. I'm sending these now in case others wish to comment and to allow the authors to incorporate these into their working revision.

Best wishes,

Gorry

P.S. This Last-Call will end on midnight, Friday 21st March 2008, so there are still opportunities for people to comment.


---

The WG decided that it is OK to update RFC 4342.

The document therefore also needs an UPDATES RFC43432 line in the header.

The abstract should also say:
"This document obsoletes RFC 3448 and updates RFC 4342."

The authors should add an explicit paragraph to the end of the introduction concerning the update to RFC4342, since my understanding is that RFC4342 was not intended to be updated by a change to TFRC, and we therefore need to explain this.

---
Section 3.1 page 14.

The authors seem to give two methods for calculating t_RTO. One option includes a minimum RTO setting of 1 sec, which seems like it could offer some help in stabilising the value of X_Bps in the presence of low and varying RTT, where R could vary by many orders of magnitude. As I read it, this is not the default. What are you recommending?

---
Section 3.1 page 14. NiT
/max(4R/ seems to be written /max(4*R/ in other places.

---
Section 4.1 page 17.

The TFRC sender can either compute the average segment size or use the maximum segment size for the segment size s. This seems a problem, for applications where the segment size varies. I'd expect many applications to start exchanging control data that is either larger or smaller than used in the remainder of the session. Since the segment size can be different by two orders of magnitude, this seems a significant issue. Bounding s to the largest segment size used would seem one possibility, setting this to the largest possible segment size.

- Current guidance is weak, and includes only a MAY followed by another MAY indicating a longer (but unbounded) measurement interval.

I would like to see some more careful RFC2219 language here: Is there some size that MUST be the upper bound? Is there some upper bound on the measurement period, or at least a recommended upper bound?

---
Section 4.1 page 17.

Two algorithms are suggested for initialising the loss history. There is no guidance on which is recommended. If there is different applicability, please say, if they are both equivalent, please choose and recommend one as the default.

---
Section 4.3 page 19.

The role of t_delay should be briefly mentioned here.

---
Section 4.6 page 26.

True, TCP could send upto one RTT's of packets in a burst. I thought pacing of the TCP sender was also encouraged and this had received some deployment?

---
Section 4.6 page 27.

TFRC MAY use pacing... Given the assertion that this is slower than the currently deployed TCP. Is this really true?

I'd have liked to have seen a more strong encouragement to support the use of pacing (at least prevention of large bursts), since a bursty source raises significant issues when sharing link capacity.

---
Section C page 51.
The para staring, /In particular, ..../ could be better phrased as in
/In particular, an Experimental RFC [RFC2861] specifies.../

---


NiTs

Please replace
/doesn't/does not/
/can't/can not/
/hasn't/has not/
/immdiately/immediately/






[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