Khi triển khai thực hiện Reno TCP năm 1990, người ta giữ nguyên các cải tiến
đã thực hiện trong Tahoe TCP, nhưng sửa đổi thuật toán phát lại nhanh FRXT, để
FRCV). Thuật toán mới này nhằm tránh cho “đường ống” khỏi bị rỗng sau khi có một gói số liệu bị mất, phải thực hiện phát lại nhanh - FRXT, rồi sau đó phải dùng SS đểđổđầy đường ống [27], [33].
Hoạt động của FRCV dựa trên giả thiết rằng, mỗi biên nhận lặp cho biết có một gói số liệu đã ra khỏi “đường ống”. Giả thiết này chỉ đúng khi trong một cửa sổ
phát, chỉ có một gói bị mất. Như vậy, trong giai đoạn FRCV bên gửi của kết nối TCP thực hiện một sự đánh giá thông minh về lượng dữ liệu đã đưa vào mạng nhưng còn chưa được biên nhận. Bên gửi sẽ đi vào giai đoạn FRCV sau khi nhận
được một giá trị ngưỡng của số biên nhận lặp, được ký hiệu là tcprexmtthresh (tcp retransmit threshold) và thường được gán giá trị bằng 3. Khi số biên nhận lặp nhận
được đạt tới ngưỡng, bên gửi sẽ phát lại một gói số liệu rồi, sau đó giảm cửa sổ tắc nghẽn cwnd xuống còn một nửa (chứ không phải giảm xuống 1 nhưở Tahoe TCP). Sau đó cứ mỗi lần nhận được một biên nhận, bên gửi lại gửi đi một gói số liệu.
Hình 4.2 Hoạt động của Reno TCP, trường hợp có một gói số liệu bị loại bỏ
Như vừa phân tích, trong Reno TCP, bên gửi được phép sử dụng cửa sổ có kích thước bằng min(awin, cwnd+ndup), trong đó awin (advertised window) ký hiệu kích thước cửa sổ mà bên nhận báo cho bên gửi, cwnd là cửa sổ tắc nghẽn của bên gửi đã được nói đến ở các phần trên. Tham số ndup luôn luôn được gán giá trị 0, chỉ
khi nào số biên nhận lặp ≥tcprexmtthresh, ndup mới bắt đầu đếm số biên nhận lặp tiếp tục đến. Sau khi đi vào giai đoạn FRCV và đã phát lại một gói số liệu, bên gửi sẽ chờ cho đến khi nhận đủ số biên nhận lặp bằng một nửa kích thước cửa sổ, sau đó cứ mỗi biên nhận lặp đến nó lại gửi đi một gói số liệu. Đến khi nhận
được một biên nhận mới, được gọi là “biên nhận khôi phục”, bên gửi mới ra khỏi giai đoạn FRCV bằng cách gán giá trị ndup=0 và giảm cửa sổ tắc nghẽn cwnd xuống còn một nửa. Bên gửi sẽ phát lại nhiều nhất là một gói số liệu bị loại trong khoảng thời gian khứ hồi. So với Tahoe, Reno TCP cải thiện đáng kể hiệu năng về
thông lượng nếu chỉ có nhiều nhất là một gói số liệu bị loại trong các gói số liệu của một cửa sổ. Tuy nhiên, hiệu năng của Reno TCP sẽ bị giảm trầm trọng nếu trong một cửa sổ có trên một gói số liệu bị loại [33].
Hình 4.2 minh hoạ hoạt động của Reno TCP, trong trường hợp cửa sổ có một gói số liệu bị loại. (Tại mục 4.1.5 cũng có một số giải thích liên quan đến hình vẽ này).