GIAO THỨC RTP

RTP ( Real Time Transport Protocol )

(Bài viết này nhằm mục đích ôn lại kiến thức và chia sẻ với những ai quan tâm. Chắc chắn sẽ có sai sót, mong mọi người cùng góp ý.
Bài viết đòi hỏi người đọc phải có kiến thức nhất định về Networking)
Bài viết tham khảo các tài liệu :
1.RFC3550
2.Bài giảng môn Multimedia and Quality of Service – Jean-Loup Guillaume
3.Bài báo “Ttimer reconsideration for Enhanced RTT scalability” – J. Rosenberg and H. Schulzrinne.
4.……
RTP được thiết kế cho các dịch vụ thời gian thực end-to-end, như các ứng dụng interactive audio và video, sử dụng các dịch vụ mạng unicast hoặc multicast. Các ứng dụng sử dụng RTP chạy trên nền của giao thức UDP ( TCP cũng có thể sử dụng nhưng rất ít), nhằm sử dụng các dịch vụ mutiplexing và check sum của UDP.
Tổ hợp giao thức bao gồm 2 giao thức RTP và RTCP (RTP control protocol). RTP được sử dụng để truyền tải thông tin dữ liệu thời gian thực. Trong khi đó RTCP được sử dụng để giám sát chất lượng dịch vụ cũng như truyền tải các thông tin điều khiển và xác nhận của phiên làm việc.
Mỗi giao thức dùng một port riêng biệt, thông thường port chẵn sử dụng cho RTP và port lẻ kế tiếp còn trống được sử dụng cho RTCP.
Vì truyền tải trong môi trường IP với UDP protocol nên việc mất gói (loss), không đúng thứ tự gói tin (out of order), trể (delay and jitter) là không thể tránh khỏi. Để hạn chế tác động của các vấn đề này, RTP & RTCP sử dụng các trường thời gian (timestamp), và sequency number trong phần header để đo đạt các thông số loss rate, delay, jitter, RTT…, phần giải pháp cho các vấn đề này do các ứng dụng giải quyết.
Cấu trúc gói tin RTP bao gồm các trường chính như sau (xem định dạng trong RFC3550):
Trường PT ( Payload Type) xác định cách thức mã hóa dữ liệu trong gói tin RTP, được định nghĩa bởi các profile. Vì mỗi gói tin đều có PT nên cho phép các gói tin được thay đổi cách thức mã hóa trong quá trình truyền trên mạng ( ta sẽ thấy rõ ưu điển này với các chức năng mixer và translator của RTP ).
Sequence number được tăng thêm bởi 1 đối với từng gói tin, giá trị khởi đầu ( của gói tin đầu tiên ) được chọn ngẫu nhiên để nhằm mục đích bảo mật. Xem xét giá trị trong trường này, receiver có thể xác định được gói tin bị mất hoặc out of oder tính tóan sác xuất mất gói hay để điều chỉnh thời gian playout của dữ liệu nhằm đảm bảo chất lượng của dịch vụ.
Timestamp được sử dụng để tính tóan đồng bộ cũng như jitter của dữ liệu, vì vậy giá trị trong trường này luôn tăng một cách tuyến tính và đơn điệu tùy thuộc theo xung clock lấy mẫu được sử dụng cho từng lọai dữ liệu ( vd video là 90kHz) bắt đầu từ thời điểm byte đầu tiên của gói RTP. Giá trị đầu tiên cũng được chọn ngẫu nhiên.
SSRC là thông tin về nguồn của dữ liệu để đồng bộ trong quá trình phát và nhận dữ liệu ( bởi vì một ứng dụng có thể có nhiều nguồn dữ liệu, ví dụ như voice và data trong video). Giá trị này cũng được chọn ngẫu nhiên để đảm bảo không bị trùng 2 SSRC trong cung một phiên RTP.
CSRC liệt kê tất cả các nguồn được kết hợp để tạo ra dữ liệu trong gói tin RTP. Số lượng các nguồn dữ liệu được cho trong trường CC. CSRC được thêm vào khi qua bộ mixer kết hợp nhiều nguồn dữ liệu lại với nhau.

Để giám sát thông tin của 1 phiên làm việc RTP, RTCP sử dụng các report (SR và RR) để trao đổi các thông tin giữa Sender và Receiver ( ngòai ra còn có các lọai gói RTCP như SDES ( mô tả thông tin nguồn), BYE ( thông báo rời bỏ session), APP (các chức năng của ứng dụng) ).

Thông số RTT ( từ đây để tính tóan các thông số chất lượng khác như delay, jitter…) được tính tóan dựa trên các trường LSR ( chứa thông tin timestamp của gói tin SR nhận được gần nhất) và DLSR ( thòi gian kể từ khi nhận được gói tin SR gần nhất đến lúc gói tin RR được phát đi) cùng với thòi gian hiện tại mà Sender nhận được gói tin RR từ Receiver.

Các ứng dụng thời gian thực được triển khai cho các dich vụ multicast hoặc unicast. Đối với hầu hết các firewall đều không cho phép địa chỉ multicast đi qua. Vì vậy Translator được sử dụng như một RTP-level relay trong trường hợp này. Hai Translators được sử dụng ở hai sides của firewall nhằm mụch đích tunneling RTP multicasting packets qua firewall bởi một kết nối bảo mật.

Một lọai RTP-level relay khác là Mixer, được sử dụng để kết hợp nhiều luồng dữ liệu từ nhiều nguồn khác nhau thành một luồng dữ liệu mới hoặc để thay đổi phương thức mã hóa thông tin thích hợp với các tốc độ đường truyền khác nhau trên mạng ( ví dụ như từ nhiều nguồn với đường truyền tốc độ cao đến đích có đường truyền tốc độ thấp).

Do Translator chỉ ánh xạ một-một các gói tin RTP nên các thông số SSRC hay các RR, SR đều được passthrough qua Translator. Trong khi đó Mixer thay đổi hòan tòan gói tin RTP nên Mixer sẽ là SSRC của gói tin vừa tạo, đồng thời tạo ra các kênh điều khiển để trao đổi các gói tin RTCP vói nguồn cũng như đích đến của dữ liệu gốc ( Mixer đóng vai trò là đích đối với nguồn dữ liệu, và là nguồn đối với đích đến của dữ liệu).

Đến đây, ta đã nắm được khái niệm, cách họat động cơ bản của giao thức RTP/RTCP, phần tiếp theo sẽ tập trung mô tả các thuật tóan nhằm khắc phục các vấn đề về delay, storage và congestion trong giao thức RTP/RTCP.
Do RTCP chỉ dùng để giám sát và điều khiển nên không quan trọng bằng các gói tin dữ liệu của ứng dụng. Nhằm mục đích dành nhiều băng thông đường truyền cho các gói tin dữ liệu, nên thông thường, các gói tin RCTP chỉ chiếm khỏang 5% dung lượng đường truyền dành cho dịch vụ dùng RTP.

Nếu xem xét trường hợp 1000 users kết nối multicast RTP, băng thông đường truyền cho mỗi user là 28.8kb/s. Gói tin RTCP là 128 bytes.

Với hạn chế 5% dung lượng cho RTCP ta có 0.05x28.8 = 1.4 kb/s cho việc truyền RTCP.

Với kích thước là 128byte = 1024bits = 1kb/s => trong 1s 1000s users truyền được trung bình 1.4/1=1.4 RTCP packet.

=>thời gian trung bình để một user có thể truyền gói tin RTCP : 1000/1.4 = 711s.

Việc truyền gói tin RTCP trể, đồng nghĩa vói tham số DRSL lớn, dẫn đến thông số delay cao. Càng nhiều users sử dụng, càng ít gói RTCP được gởi cho mỗi user => càng ít thông tin điều khiển => Delay là một vấn đề của các ứng dụng thời gian thực.

Như ta thấy, một client muốn truyền dữ liệu phải căn cứ số lượng các clients sử dụng chung một phiên RTP.

Giả sử rằng có 10000 clients tham gia một phiên RTP, nhưng các clients chỉ dự đóan khỏang 1000 clients đang họat động, các clients chỉ tính tóan trên con số 1000 để chiếm 5% băng thông cho RTCP, tuy nhiên thực tế số clients gấp 10 lần nên băng thông thực sự RTCP chiếm là 50% ( 5%x10). Sự tắc nghẽn sẽ xảy ra tồi tệ hơn nếu, các clients chỉ đánh giá khỏang 10 clients tham gia thay vi con số thực tế là 10000.

Để đánh giá được số lượng các clients tham gia vào một phiên RTP, các client lưu giữ một bảng thông tin chứa tất cả các SSRC giao dịch trong ứng dụng. Điều này lại làm nảy sinh thêm một vấn đề nghiêm trọng đó là khả năng lưu trữ của hệ thống.

Tuy nhiên, các bảng thông tin SSRC được thành lập dựa theo các report được gởi bởi các client trên mạng, vì vậy nó cần thời gian để có đủ thông tin chính xác ( quá trình đồng bộ dữ liệu). Xét trường hợp rất nhiều client cùng tham gia vào thời điểm bắt đầu của ứng dụng. Mỗi client đều giả sử rằng, nó là client duy nhất sử dụng dịch vụ, nên sử dụng 5% băng thông để gởi RTCP. Với 20 clients, băng thông đường truyền được sử dụng hết cho RTCP, nếu số lượng client tham gia quá nhiều sự tắt nghẽn là cực kỳ nghiêm trọng.

Thực sự, các client tham gia vào một nhóm multicast RTP, để tính tóan thời gian bắt đầu gởi gói tin, RTCP sử dụng các thông số sau :

C : khỏang thời gian giữa hai lần nhận thành công gói tin RTCP bất kỳ.

L(Tn) : là số lượng client hiện có trong nhóm. L(T0)=1 là lúc client mới gia nhập vào nhóm.

Thời điểm truyền gói tin tiếp theo được xác định theo công thức :

Tn = T(n-1) + R(a)*max(Tmin;CL(T(n-1))

Với Tmin = 2.5 cho lần gởi đầu tiên và Tmin=5 cho các lần gởi tiếp theo.

R(a) là hàm random trong khỏang [1-a ;1+a], |a|<1, hiện tại thường R(a)=1/2

L(T) được thống kê theo thực tế.

Vấn đề còn lại phải xác định được thông số C.

Ta thấy C*L(T) la khỏang thời gian nhận thành công 2 gói tin RTCP từ một SSRC, cũng là thời gian giữa hai lần gởi gói tin RTCP. Vì vậy, tốc độ gởi RTCP được xác định bằng :

(|RTCP|size * L(T) )/C. Tốc độ này phải thỏa mãn <=5%BW.

(|RTCP|size * L(T) )/C <=5%BW.

C>= (|RTCP|size * L(T) )/(5%BW).

Với thuật tóan này, ta xét trường hợp T0, với số lượng client tham gia vào nhóm rất nhiều. Tất cả các client đều gởi gói tin RTCP đầu tiên trong khỏang thời gian từ 1.25s đến 3.75s. trong khỏang thời gian này, vấn đề nghẽn mạng rất nghiêm trọng. Để hạn chế một phần vấn đề này, một thuật tóan được đưa ra là reconsideration. Khái niệm chính của reconsideration là trước khi truyền gói tin RTCP, client sẽ tính tóan lại thòi gian truyền gói tin Trecon(n) dựa trên giá trị L(T) hiện tại của nó nếu như giá trị này đã được thay đổi trong khỏang thời gian kể từ lúc tính tóan trước ( T(n-1) đến T(n)). Nếu Trecon(n)<=T(n) thì gói tin được gởi, ngược lại gói tin sẽ đợi đến thời điểm Trecon(n). Tới thời điểm Trecon(n), nếu giá trị L(T) thay đổi thì quá trình reconsideration lặp lại. Đây là thuật tóan conditional reconsideration ( điều kiện L(T) thay đổi). Với cách giả quyết này, vấn đề tắt nghẽn chỉ còn xảy ra với các client chọn giá trị R(a) nhỏ. Với các client chọn giá trị R(a) lớn, sẽ nhận được gói tin RTCP trược khi truyền nên sẽ tính tóan lại thời điểm truyền, một số gói tin sẽ delay thêm một khỏang thời gian. Chính điều này làm giảm mức độ tình trạng tắt nghẽn. Tuy nhiên bù lại việc tính tóan sẽ xảy ra thường xuyên hơn.

Đối với thuật tóan unconditional reconsideration, việc tính tóan luôn luôn được thực hiện lại dù giá trị L(T) có thay đổi hay không. Thuật tóan này tận dụng kết quả của hàm random R(a) để cho các giá trị T(n) khác nhau. Thậm chí đối với các client chọn giá trị R(a) nhỏ chưa kịp thay đổi L(T), vẫn có khả năng bị delay. Vì vậy mức độ nghẽn mạng được cải thiện tốt hơn.