Poprawna jest klasa UBR (Unspecified Bit Rate), bo dokładnie ona w ATM jest przewidziana dla źródeł o niezdefiniowanej szybkości transmisji, które wysyłają duże porcje danych nieregularnie i tylko wtedy, kiedy w sieci jest wolne pasmo. W UBR sieć ATM nie gwarantuje żadnych parametrów jakościowych typu przepływność minimalna, opóźnienie czy jitter. Moim zdaniem najlepiej kojarzyć UBR z ruchem typu „best effort”, bardzo podobnie jak w klasycznym internecie – jak jest miejsce, to dane jadą, jak nie ma, to czekają albo są odrzucane. Typowe zastosowania to np. transfer plików, kopie zapasowe, ruch e‑mail, różne zadania wsadowe, gdzie nie ma ostrych wymagań czasowych. W standardach ATM (ITU-T I.371, rekomendacje ATM Forum) UBR opisuje się jako klasę bez gwarancji QoS, przeznaczoną właśnie dla ruchu tła, dużych, sporadycznych zlewek danych, gdzie ważniejsza jest efektywność wykorzystania łącza niż czas dostarczenia. W konfiguracji sieci inżynierowie zwykle rezerwują zasoby dla klas CBR czy rt-VBR, a pozostałe „dziury” w paśmie wypełniają ruchem UBR. UBR nie wymaga skomplikowanej sygnalizacji parametrów ruchu – źródło po prostu wysyła komórki w miarę potrzeb, a sieć może je odrzucać przy przeciążeniu bez łamania żadnej umowy ruchowej. Z mojego doświadczenia warto pamiętać, że UBR jest idealny tam, gdzie ewentualne straty lub większe opóźnienia nie rozwalą aplikacji, ale za to pozwalają maksymalnie dociążyć łącze i nie marnować przepustowości, która i tak by się marnowała, gdy aplikacje czasu rzeczywistego akurat nic nie wysyłają.
W technologiach ATM każda klasa ruchowa jest projektowana pod konkretny typ źródła i konkretne wymagania jakościowe. Problem pojawia się wtedy, gdy próbujemy „na siłę” dopasować ruch o nieregularnym charakterze i niezdefiniowanej szybkości do klas przeznaczonych dla bardziej przewidywalnych strumieni. To jest dość typowy błąd myślowy: skoro dana klasa ma w nazwie „bit rate”, to wydaje się, że nada się do wszystkiego, co przesyła dane, ale w ATM to tak nie działa. CBR, czyli Constant Bit Rate, jest przeznaczona dla źródeł generujących prawie stały strumień danych, z bardzo ostrymi wymaganiami na opóźnienie i jitter. Przykłady to klasyczna telefonia cyfrowa, strumieniowanie głosu w czasie rzeczywistym, niektóre aplikacje wideo czasu rzeczywistego. W CBR rezerwuje się stałe pasmo, niezależnie od tego, czy źródło w danym momencie faktycznie wysyła dane. Dla ruchu nieregularnego, dużych „zlewek” informacji, takie podejście byłoby po prostu marnotrawstwem przepustowości i łamaniem dobrych praktyk inżynierii ruchu. ABR (Available Bit Rate) z kolei jest klasą adaptacyjną. Sieć udostępnia źródłu pewien zakres przepływności, ale źródło może dynamicznie dostosowywać swoją szybkość na podstawie informacji zwrotnych od sieci (mechanizmy kontroli przepływu i przeciążenia). ABR jest sensowny dla aplikacji, które mogą regulować tempo wysyłania, ale jednocześnie oczekują pewnego minimalnego poziomu usług i sterowania przeciążeniami. To nadal nie jest idealne dla typowego „burstowego” ruchu, który z definicji nie ma jasno określonej szybkości, a często też nie potrzebuje żadnych gwarancji. GFR (Generic Frame Rate) bywa mylony z UBR, bo też jest wykorzystywany do ruchu danych. Jednak GFR jest zoptymalizowany pod przesyłanie ramek (np. z sieci Ethernet) i zapewnia pewne minimalne gwarancje dla całych ramek, jeśli są one odpowiednio oznaczone i mieszczą się w zadeklarowanych parametrach. Wymaga to już dokładniejszego planowania i nie jest to czysto „best effort”. Dlatego dla źródeł o kompletnie niezdefiniowanej szybkości i nieregularnych, dużych porcjach danych lepsza jest klasa UBR, która nie obiecuje QoS, ale pozwala efektywnie wykorzystywać wolne zasoby. W praktyce warto więc zapamiętać: gdy myślimy o ruchu czasu rzeczywistego – patrzymy na CBR i odpowiednie VBR; gdy myślimy o ruchu wrażliwym, ale elastycznym – rozważamy ABR lub GFR; gdy mamy zwykły ruch tła, duże, sporadyczne transfery i brak wymagań co do opóźnień – wtedy dopiero UBR jest naturalnym wyborem.