Re: Some comments on Faster Restart rev-01

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

 



Hi Gorry!

Gorry Fairhurst wrote:
Some thoughts in-line on the latest version of the draft...

Best wishes,

Gorry

* TFRC is within the Charter of the DCCP WG, so that is fine. My question is
to whether the authors intend this to be also proposed as a method for DCCP
(which I think is also applicable). If so, should the Introduction also say
this?

Yes, it is intended as such.

    The congestion control mechanisms here are intended to apply to any
    implementations of TFRC, including that in DCCP's CCID 3 [RFC4342].
    While we also believe that TCP could safely use similar mechanisms,
    we do not specify them here.


* I like the new discussion of the "meaning/behaviour of the idle period" -
but perhaps this thinking still needs to be further developed? - Perhaps
something we could start in the face-to-face WG meeting and then take on the
list?

Not sure what you mean, actually?

* Page 9
- Capacity can also change quickly when the L2 network allocates capacity
based on traffic conditions (BoD). Such methods are common across a range of
wireless technologies, and can take several RTTs to adapt to changes in
traffic conditions.

Got it.


-----------------=====-----------------

NiTs for consideration by authors in the next rev:

Got them.

Eddie




*page 4, X_active_rec
/receive reported/receive rate reported/
                          ^^^^^

*page 7
/to adjust feedback packets' Receive Rates/
- English could be improved.

*page 8
/and the window in re-opened/and the window is re-opened/
                                            ^^^

*page 8
/And..../
- English could be improved... "In addition,"?

*page 9
/to make everything look just like lovely white noise/
- English could be improved.

*page 9
/controlled of a sending rate/controlled by the sending rate/
                                         ^^^^^^

* section 5
/and idle periods of hours/
- To me, this seems rather understated. Can we be slightly bolder?
A sender that is idle for 30 minutes seems to me to be one that is no longer
actively part of a session. This period is of the order of routing updates.

* [JSA05] - Please update reference (unless you mean to cite the pre-WG version of the
document.





[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