Rephrase text around algorithmic alternatives.

[larseggert]

Fixes #90.

[markkukojo]

W.r.t. slow start:
This text is now better than the original.
However, is there any real reason to make CUBIC dependant of HyStart++?
Isn't HyStart++ similarly useful extension to the RFC 5681 slow start?
Moreover, it is now SHOULD, why is it not MUST? This begs for explaining when it might be justified to not implement HyStart++ with CUBIC.
IMO, If we want to recommend HyStart++, it is better done in HyStart++ spec.

And a nit: Reno TCP slow start algorithm does not make any sense to me. Reno is one alternative loss recovery algorithm to be applied after a Fast Retransmit. The one that first was implemented for BSD 4.3 Reno. The predecessor was Tahoe, which applied slow start after a Fast Retransmit. Later alternatives include NewReno and SACK-based loss recovery.

[sangtaeha]

I don't think we have to mandate the use of a specific slow start algorithm even though Linux CUBIC uses Hystart. In fact, HyStart++ uses one of two indicators (delay spike) of Hystart (ack train length and delay spike). Can we just say any advanced slow start algorithms can be used for CUBIC?

[larseggert]

There is only one on the standards track, and that is HyStart++, so I made that the SHOULD. Others area allowed experimentally.

[larseggert]

Note: unless someone objects, I will merge this PR soon. If you do object, please make a concrete proposal for what would need to change.

[huitema]

Seems ready.

[nealcardwell]

LGTM, thanks!

[sangtaeha]

Looks good to me. Thanks!