W rozmowie na żywo spóźniony pakiet może być mniej użyteczny niż zgubiony
W przesyłaniu pliku brakujący fragment trzeba odzyskać, nawet jeśli zajmie to chwilę. W rozmowie głosowej lub wideokonferencji sytuacja jest inna: pakiet zawierający fragment dźwięku sprzed sekundy może dotrzeć już po chwili, w której miał zostać odtworzony. RFC 4588 podkreśla, że retransmisję RTP należy stosować tylko wtedy, gdy ponownie wysłany pakiet ma szansę dotrzeć, zanim przestanie być użyteczny; podobne ograniczenia opisuje WebRTC. Dlatego protokoły czasu rzeczywistego czasem świadomie tolerują niewielką stratę zamiast czekać na perfekcyjne odtworzenie strumienia.
Plik i rozmowa mają inne pojęcie poprawności
Przy pobieraniu archiwum liczy się dokładna zgodność każdego bajtu. Jeżeli fragment zginie, lepiej poczekać i go retransmitować niż zapisać uszkodzony plik. W rozmowie głosowej informacja ma dodatkowy termin ważności. Fragment wypowiedzi potrzebny w chwili 12,5 s może być bezużyteczny, jeśli pojawi się dopiero w 13,5 s, bo rozmowa zdążyła przejść dalej.
RTP nie obiecuje dostarczenia
RFC 3550 opisuje RTP jako protokół transportu danych czasu rzeczywistego, zwykle działający nad UDP. RTP dostarcza znaczniki czasu, numery sekwencyjne i informacje potrzebne aplikacji, ale sam nie gwarantuje dostarczenia ani określonego czasu dotarcia. Aplikacja może dzięki numerom zauważyć stratę i zdecydować, jak na nią reagować.
Retransmisja ma budżet czasu
RFC 4588 definiujący retransmisję RTP zaznacza, że metoda jest użyteczna tylko wtedy, gdy ponowiony pakiet dotrze przed momentem, w którym jest jeszcze przydatny. Jeśli RTT jest duże, ponowne wysłanie może zakończyć się sukcesem technicznym, ale porażką użytkową: odbiorca dostanie idealny fragment zbyt późno. System musi znać tolerancję opóźnienia aplikacji.
Czasem lepiej zamaskować stratę
Kodeki audio i wideo potrafią stosować concealment, interpolację, powtarzanie poprzednich próbek lub inne techniki ukrywania krótkich ubytków. Efekt nie jest matematycznie identyczny z oryginałem, ale rozmowa pozostaje płynna. Inne systemy wykorzystują nadmiarowość lub forward error correction, żeby odtworzyć część strat bez czekania na pełną podróż żądania retransmisji i odpowiedzi.
WebRTC dobiera mechanizmy do sytuacji
RFC 8834 omawia retransmisje i inne mechanizmy odzyskiwania w kontekście WebRTC. Nie istnieje jedna zasada „zawsze retransmituj” dla całego medium. Decyzja zależy od kodeka, rodzaju pakietu, szacowanego RTT i tego, ile opóźnienia aplikacja może jeszcze zaakceptować. Ten sam Internet przenosi więc pliki i rozmowy według różnych kompromisów na warstwie aplikacji.
Niezawodność nie jest wartością absolutną
W sieciach określenie „bardziej niezawodny” może być mylące, jeśli nie powiemy, co aplikacja uznaje za sukces. Dla kopii zapasowej sukces oznacza wszystkie bity bez błędów. Dla interaktywnego audio może oznaczać ciągłość i niskie opóźnienie nawet kosztem utraty drobnego fragmentu. Projekt protokołu jest wyborem między poprawnością, świeżością i czasem, a nie wyścigiem do maksymalnej liczby gwarancji.
Numer sekwencyjny może być użyteczny nawet bez retransmisji
W transmisji czasu rzeczywistego brak gwarancji dostarczenia nie oznacza braku informacji o stracie. RTP numeruje pakiety i oznacza je znacznikami czasu, dzięki czemu odbiorca wie, że fragment zniknął oraz gdzie powinien znajdować się na osi odtwarzania. Może wtedy dobrać reakcję: spróbować retransmisji, użyć nadmiarowości, zastosować concealment albo po prostu pominąć brak. To zasadnicza różnica względem ślepego przesyłania datagramów. Aplikacja otrzymuje narzędzia do oceny, czy naprawa ma jeszcze sens. W rezultacie system może być mniej „idealny” bit po bicie, ale bardziej użyteczny dla człowieka. Sieci czasu rzeczywistego optymalizują doświadczenie w określonym terminie, a nie abstrakcyjną kompletność danych niezależnie od tego, kiedy zostaną dostarczone. Wideo dodatkowo komplikuje sytuację, bo nie wszystkie fragmenty obrazu mają równą wagę. Utrata danych potrzebnych jako podstawa dla kolejnych klatek może być bardziej kosztowna niż utrata pojedynczej informacji możliwej do zamaskowania. Dlatego decyzje o retransmisji mogą zależeć nie tylko od RTT, ale również od tego, co konkretny pakiet wnosi do dekodowania przyszłego strumienia.