tcp reno, newreno and slow start

When packet loss occurs while in slow开发者_JS百科 start, does the reno/newreno algorithms notice possible dupacks, or is it purely slowstart -> rto?

Thus, if sending two packets (in start of slow start), and first one goes missing, does slow start do anything else but rto?

It is confusing, since rfc states that 'in practice they (slow start & congestion avoidance) are implemented together'. And linux source is a bit thick read and only one implementation.

When packet loss occurs while in slow start, does the reno/newreno algorithms notice possible dupacks, or is it purely slowstart -> rto?

I would say "yes", duplicate ACKs will be detected and acted upon. See RFC 2001, Section 2.3.

Thus, if sending two packets (in start of slow start), and first one goes missing, does slow start do anything else but rto?

This particular example would lead to a "simple RTO". During the beginning of slow start when only two packets can be sent there will at most be one duplicate ACK (triggered by the second packet arriving). There might even be none if both packets are (would be) acknowledged together. But one duplicate ACK does not trigger fast retransmit. So TCP will wait for the retransmission timer to expire.

It is confusing, since rfc states that 'in practice they (slow start & congestion avoidance) are implemented together'. And linux source is a bit thick read and only one implementation.

I agree that the linux source is a thick read. But it's definitive and if you really need to know might be the only option :) Unless you find someone who read (or wrote) it; which I have not.