Nén tải nhằm tăng dung lượng băng thông liên kết. Tuy nhiên, việc nén tải
sẽ làm tăng độ trễ trong việc truyền dẫn do phải cần khoảng thời gian dài để
thực hiện những thuật toán nhằm giải quyết việc nén dữ liệu.
Một cơ chế nén hiệu quả hơn đó là nén phần header. Cơ chế nén này đặc
biệt hiệu quả đối với những mạng có gói chứa dữ liệu nhỏ ( tỉ số tải trên
header là nhỏ).
1.3.4.2 Giảm trễ
Để giảm trễ trong mạng, dưới đây là một số giải pháp:
Tăng dung lượng liên kết, với một dung lượng băng thông vừa đủ trên liên
kết sẽ giúp rút ngắn chiều dài hàng đợi và như vậy gói sẽ không phải đợi
lâu để được truyền đi. Mặt khác, thời gian phát định kỳ sẽ được giảm
xuống. Tuy nhiên giải pháp sẽ không được khả thi do cùng việc tăng dung
lượng thì giá thành cũng sẽ tăng theo.
Một giải pháp có tính hiệu quả hơn đó là tạo ra một cơ cấu hàng đợi có hỗ
trợ quyền ưu tiên đối với những gói có yêu cầu độ trễ nhỏ bằng cách đưa
các gói tin này lên hàng đầu.
Nén tải sẽ giảm được kích thước của gói và từ đó sẽ tăng được băng thông
liên kết. Thêm vào đó, kích thước gói sẽ nhỏ hơn sau khi nén tải và gói sẽ
yêu cầu thời gian truyền ngắn hơn. Tuy nhiên, để thực hiện nén tải cần
được thực hiện thông qua các thuật toán phức tạp. Giải pháp này thường
không được sử dụng đối với những gói truyền trong môi trường có độ trễ
nhỏ.
Việc nén header không là công việc tập trung xử lý chính mà nó sẽ được
kết hợp với các kỹ thuật khác để giảm độ trễ. Phương thức này đặc biệt phù
hợp với gói là voice.
Bằng cách giảm độ trễ truyền dẫn thì độ trượt cũng được giảm đáng kể.
1.3.4.3 Ngăn mất gói
Mất gói thông thường xảy ra khi router không còn thời gian bộ đệm phục vụ
cho việc xếp hàng đợi. Router sẽ thực hiện loại bỏ gói trong những trường hợp
sau:
CPU bị nghẽn và không thể xử lý gói.
Router không còn không gian bộ đệm
CPU bị nghẽn và không thể ấn định một không gian bộ đệm nào cho các
gói mới
Lỗi khung (ví dụ CRC).
Sau đây là một số giải pháp giúp tăng ngăn chặn mất gói đối với các ứng dụng:
Tăng dung lượng liên kết để tránh nghẽn.
Đảm bảo đủ lượng băng thông và tăng không gian bộ đệm nhằm đáp ứng
được khi xảy ra bùng nổ thông tin.
Tránh nghẽn bằng cách loại bỏ gói trước khi nghẽn xảy ra. WRED sẽ được
sử dụng để thực hiện loại bỏ gói trước khi xảy ra nghẽn.
{{{
Hình 1.3 Tránh nghẽn ngăn mất gói
1.4 Các kiểu dịch vụ QoS trong mạng
Định nghĩa kiến trúc QoS ra đời vào giữa năm 1990, và cho đến nay nhóm
nghiên cứu IETF (Internet Engineering Task Force) đã định nghĩa hai dạng kiến
trúc QoS cho mạng IP đó là các dịch vụ tích hợp (IntServ) và các dịch vụ phân
biệt (DiffServ).
1.4.1 Dịch vụ tích hợp Intserv
Các dịch vụ tích hợp (Intserv) được nhóm nghiên cứu IETF đưa ra nhằm
cung cấp các dịch vụ end-to-end giữa các máy chủ cho các ứng dụng point-to-
point và point-to multipoint . Nó định nghĩa quá trình xử lý báo hiệu cho các luồng
riêng biệt và yêu cầu phải dự trữ một lượng băng thông và độ trễ nhất định. Để
đảm bảo cho mỗi dòng, IntServ mô tả hai thành phần: dự trữ tài nguyên và điều
khiển lưu lượng. Dự trữ tài nguyên cho phép luồng dữ liệu riêng biệt yêu cầu một
IP Data FI FO
queuing
Custom Queuing (CQ)
Modified Deficit Round
Robin (MDRR)
Weighted Random Early
Detection (WRED)
lượng băng thông và độ trễ thích hợp. Nếu việc báo hiệu thành công, thì các thành
phần mạng sẽ phải dự trữ lượng băng thông cần thiết. Còn điều khiển lưu lượng
Intserv sẽ quyết định yêu cầu dự trữ nào sẽ bị từ chối. Nếu tất cả các yêu cầu được
chấp nhận thì sẽ có quá nhiều luồng lưu lượng đi trong mạng và kết quả sẽ không
có luồng nào được nhận dịch vụ yêu cầu cả.
Hình 1.4 Kiến trúc dịch vụ Intserv
1.4.1.1 Giao thức dự trữ tài nguyên RSVP (Resource Reservation Protocol)
RSVP là một giao thức cho việc thiết lập các dự trữ tài nguyên. Giao thức
RSVP được các máy chủ sử dụng để yêu cầu các chất lượng dịch vụ đặc biệt từ
mạng cho các ứng dụng riêng biệt như các dòng dữ liệu hay các luồng thông tin.
Các router cũng có thể sử dụng giao thức này để thiết lập, duy trì và phân phối các
yêu cầu QoS cho các node hoạt động dọc theo đường dẫn. Kết quả là các tài
nguyên sẽ được dự trữ cho mỗi node theo đường dữ liệu.
RSVP phải mang các thông tin sau:
Thông tin phân loại, nhờ nó mà các luồng lưu lượng với các yêu cầu QoS
cụ thể có thể được nhận biết trong mạng. Thông tin này bao gồm địa chỉ IP
phía gửi và phía nhận, số cổng UPD.
Chỉ tiêu kỹ thuật của luồng lưu lượng và các yêu cầu QoS
Rõ ràng là RSVP phải mang những thông tin này từ các máy chủ tới tất cả
các tổng đài chuyển mạch và các router dọc theo đường truyền từ bộ gửi đến bộ
nhận, vì vậy tất cả các thành phần mạng này phải tham gia vào việc đảm bảo các
yêu cầu QoS của ứng dụng.
1.4.1.2 Cách thức hoạt động của RSVP
Cách thức hoạt động của RSVP dựa trên việc giành dự trữ tài nguyên trước
khi truyền dữ liệu. Có hai loại bản tin RSVP chính được sử dụng để báo hiệu. Bên
gởi sẽ gởi bản tin đường dẫn PATH và các thông tin phân loại đến bên nhận để
xác định các thuộc tính của lưu lượng sẽ gởi. Mỗi node trung gian sẽ chuyển tiếp
bộ bản tin PATH tới các node kế tiếp. Khi nhận được bản tin PATH, bên nhận
được sẽ đáp ứng lại bằng một bản tin RESV. Bản tin RESV xác nhận phiên có
chứa thông tin về số cổng dành riêng và mức QoS mà bên nhận yêu cầu. Các node
trung gian trên đường đi có thể chấp nhận hay từ chối các yêu cầu trong bản tin
RESV. Nếu yêu cầu bị từ chối, router sẽ gởi bản tin Error cho bên nhận và quá
trình báo hiệu sẽ kết thúc. Nếu yêu cầu được chấp nhận tài nguyên sẽ được dự trữ