Ảnh hưởng của các tham số trong quản lý hàng đợi và tránh tắc nghẽn trên internet

1. Mở đầu:

Sự bùng nổ thông tin đã dẫn đến lưu lượng tin trên đường truyền Internet ngày càng lớn, sự quá tải xử lý tại các nút mạng trung tâm càng cao, có nguy cơ dẫn đến tắc nghẽn. Sự tắc nghẽn có khuynh hướng tác động lại chính nó và trở nên tồi tệ hơn nếu một bộ định tuyến không còn bộ đệm tự do, nó sẽ bỏ qua những gói tin mới đến khi mà khả năng xử lý của các nút yếu sẽ dẫn đến tắc nghẽn ở trạm nhận và buộc trạm gửi tự dừng lại để giải phóng bộ nhớ đệm tự do.

Trong thời gian vừa qua đã có một số kết quả nghiên cứu để hạn chế sự tắc nghẽn dựa vào việc tổ chức lại hàng đợi phù hợp hơn, như theo cơ chế tổ chức hàng đợi DropTail, Fair Queue, RED [1],[3],[4]. Đồng thời có nhiều cải tiến về giao thức TCP Tahoe, TCP Reno, TCP Vegas, để điều khiển luồng tránh tắc nghẽn [5]. Trong bài báo này chúng tôi phân tích ảnh hưởng của các tham số trong cơ chế quản lý hàng đợi tích cực để hạn chế tình trạng dẫn đến tắc nghẽn xãy ra tại nút mạng và ổn định lưu thông trong khoảng thời gian ngắn bùng nổ thông tin trên hệ thống mạng.

 

doc 7 trang phuongnguyen 6520
Bạn đang xem tài liệu "Ảnh hưởng của các tham số trong quản lý hàng đợi và tránh tắc nghẽn trên internet", để tải tài liệu gốc về máy hãy click vào nút Download ở trên

Tóm tắt nội dung tài liệu: Ảnh hưởng của các tham số trong quản lý hàng đợi và tránh tắc nghẽn trên internet

Ảnh hưởng của các tham số trong quản lý hàng đợi và tránh tắc nghẽn trên internet
TẠP CHÍ KHOA HỌC, Đại học Huế, Số 22, 2004
ẢNH HƯỞNG CỦA CÁC THAM SỐ TRONG QUẢN LÝ HÀNG ĐỢI 
VÀ TRÁNH TẮC NGHẼN TRÊN INTERNET
Võ Thanh Tú
 Trường Đại học Khoa học, Đại học Huế
1. Mở đầu:
Sự bùng nổ thông tin đã dẫn đến lưu lượng tin trên đường truyền Internet ngày càng lớn, sự quá tải xử lý tại các nút mạng trung tâm càng cao, có nguy cơ dẫn đến tắc nghẽn. Sự tắc nghẽn có khuynh hướng tác động lại chính nó và trở nên tồi tệ hơn nếu một bộ định tuyến không còn bộ đệm tự do, nó sẽ bỏ qua những gói tin mới đến khi mà khả năng xử lý của các nút yếu sẽ dẫn đến tắc nghẽn ở trạm nhận và buộc trạm gửi tự dừng lại để giải phóng bộ nhớ đệm tự do.
Trong thời gian vừa qua đã có một số kết quả nghiên cứu để hạn chế sự tắc nghẽn dựa vào việc tổ chức lại hàng đợi phù hợp hơn, như theo cơ chế tổ chức hàng đợi DropTail, Fair Queue, RED [1],[3],[4]. Đồng thời có nhiều cải tiến về giao thức TCP Tahoe, TCP Reno, TCP Vegas, để điều khiển luồng tránh tắc nghẽn [5]. Trong bài báo này chúng tôi phân tích ảnh hưởng của các tham số trong cơ chế quản lý hàng đợi tích cực để hạn chế tình trạng dẫn đến tắc nghẽn xãy ra tại nút mạng và ổn định lưu thông trong khoảng thời gian ngắn bùng nổ thông tin trên hệ thống mạng.
2. Cơ chế điều khiển luồng để tránh tắc nghẽn
Điều khiển luồng được xét đến ở đây là quá trình điều khiển gói báo nhận hoặc điều chỉnh kích thước cửa sổ trượt. Việc sử dụng cửa sổ trượt có kích thước thay đổi là hỗ trợ việc điều khiển tốc độ truyền dữ liệu cũng như là việc truyền đáng tin cậy. Để tránh việc nhận nhiều gói tin hơn khả năng lưu trữ, nơi nhận sẽ gửi đi thông báo cửa sổ nhỏ hơn và ngược lại. Trường hợp xấu nhất, nơi nhận sẽ gửi đi thông báo cửa sổ có kích thước là zero để ngưng tất cả việc truyền. Nhưng việc nhiều lần ngưng truyền với những đợt ngắn do tràn hàng đợi tạm thời là không cần thiết, điều này làm tăng sự dao động thông lượng. Vì vậy cần có cơ chế điều khiển hợp lý giữa luồng gói tin đến và cơ chế xử lý tại nút nhận thích hợp.
Thông thường các điểm đầu cuối thường không nhận biết sự tắc nghẽn và tại sao chúng xảy ra. Bởi vì tắc nghẽn là do sự trì hoãn gia tăng, nên hầu hết các phần mềm giao thức sử dụng bộ đếm thời gian và truyền lại. Việc truyền lại có ảnh hưởng lớn đến hệ thống vì nó sẽ làm tăng thêm sự nghẽn mạch, và đến một lúc nào đó mạng sẽ trở nên vô dụng. Vấn đề này được gọi là sự sụp đổ do nghẽn mạch. Giải quyết toàn diện vấn đề này là vô cùng phức tạp, liên quan nhiều tầng giao thức khác nhau và nhiều dịch vụ khác nhau. Thông thường việc điều khiển sự tắc nghẽn được thực hiện qua 3 bước như sau:
Bước 1: Làm chủ hệ thống để phát hiện khi nào và xảy ra ở đâu. Khi xác định được tắc nghẽn ở đâu, lúc đó bước thứ 2 sẽ được thực hiện. 
Bước 2: Chuyển thông tin đến những nút mạng (router) khác mà ở đó có thể tiến hành giải quyết được công việc đồng thời thông báo tắc nghẽn (ECN: Explicit Congestion Notification)[3] cho các router khác. Tất nhiên, các gói tin phụ sẽ làm tăng tải vào thời điểm nhiều tải không cần thiết.
Một phương pháp khác là máy chủ hay router gửi các gói tin thăm dò để biết rõ ràng về sự tắc nghẽn. Thông tin có thể được sử dụng chỉ lưu thông quanh khu vực có sự cố.
Bước 3: Khi nhận được thông tin về sự tắc nghẽn, máy chủ có những hành động thích hợp để giảm sự tắc nghẽn như: Sắp xếp lại tuyến đường truyền tin, hạn chế không cho truyền gói tin vào những đường xảy ra tắc nghẽn Các phương pháp có thể hoạt động ở trạm nguồn hoặc ở trạm đích.
Hoạt động ở trạm nguồn: Bao gồm gói tin được gửi đi, trở lại từ điểm tắc nghẽn báo cho nguồn hoặc nguồn suy đoán về sự tồn tại của tắc nghẽn bằng việc quan sát thời gian cần thiết cho sự báo nhận đi trở lại.
 Hoạt động ở trạm đích: Sự hiện diện của tắc nghẽn có nghĩa tải (tạm thời) là lớn hơn lượng tin (một phần hệ thống) có thể quản lý. Hai giải pháp có thể thực hiện để giải quyết là tăng tài nguyên (lượng thông tin có thể lưu trữ) hoặc giảm tải.
Tuy nhiên, đôi khi không thể tăng khả năng tài nguyên lên được hoặc nếu tăng thì chỉ tăng đến một giới hạn nhất định. Cách duy nhất để tác động sự tắc nghẽn là giảm tải. Để giảm tải có thể phủ nhận dịch vụ với nơi sử dụng, giảm bớt dịch vụ từ các trạm gửi đến hoặc cải tiến giao thức điều khiển phù hợp, cải tiến cơ chế xử lý gói tin tại hàng đợi của các nút mạng trung tâm theo một trực tự ưu tiên phù hợp.
3. Ảnh hưởng của tham số điều khiển trong cơ chế quản lý hàng đợi
3.1. Phương pháp luận
Khi các gói tin gửi đến nhanh hơn là chúng được chuyển đi thì hàng đợi sẽ dài ra hay các gói tin chuyển đến chậm hơn thì hàng đợi thu ngắn lại. Nhưng vì bộ nhớ là hữu hạn, hàng đợi không thể dài ra quá hạn. Vì vậy để quản lý hàng đợi bị tràn phần mềm của bộ định tuyến sử dụng chiến lược cắt bớt phần đuôi (DropTail). Chiến lược này có ảnh hưởng đáng kể với TCP, làm cho TCP đi vào trạng thái khởi động chậm, nghĩa là giảm bớt tốc độ truyền cho tới khi TCP bắt đầu nhận các báo nhận và gia tăng kích thước cửa sổ nghẽn mạch. Ngoài ra việc hủy các gói tin đến sau khi hàng đợi bị đầy có thể ảnh hưởng đến toàn bộ Internet, điều này đòi hỏi phải có một mô hình khác để thay thế đó là mô hình hủy bỏ sớm ngẫu nhiên (Random Early Discar) [5], thường được gọi tắt là RED. Cơ chế này dựa vào việc tính toán xác suất gói tin rơi trong giới hạn ngưỡng kích thước hàng đợi maxth, minth và tính toán kích thước hàng đợi trung bình tại nút mạng. Giá trị của được cập nhật mỗi khi có datagram gửi đến, theo công thức sau:
	:= (1 - ) * + * k	 (1)
Với là hệ số 01, k: kích thước hàng đợi tức thì.
Cơ chế quản lý bộ đệm RED dựa vào gói tin bị đánh rơi với một xác suất tăng dần theo hàm p() của kích thước hàng đợi trung bình , có kích thước bộ đệm của K gói tin. Việc tính hàm xác suất p là một trong những giai đoạn phức tạp của RED. 
Gọi p() là hàm xác suất gói tin rơi ta có: 
p () = = 	(2)
Hiệu số (maxth - minth) càng cao thì xác suất rơi gói tin thấp, khi hàng đợi rỗng thì xác suất hủy gói tin ngẫu nhiên p() = 0. 
k
d(k)
1
maxp
minth
maxth K
Hình 1: Xác suất rơi gói tin trên mô hình hàng đợi RED
p() = 0 nếu maxth,
Mặc dù mô hình tuyến tính hình thành nên cơ sở của phép tính xác suất cho RED, cần phải có những hiệu chỉnh trọng số để tránh tình trạng phản ứng “quá vội”. Sở dĩ cần có những thay đổi là bởi vì giao thông trên mạng là theo từng “đợt”, và gây ra những dao động quá nhanh của hàng đợi trong bộ định tuyến. Nếu RED sử dụng một mô hình tuyến tính đơn giản, những gói tin đến sau trong mỗi đợt sẽ bị gán xác suất cao cho khả năng bị loại bỏ (bởi vì chúng đến khi hàng đợi đã có nhiều gói tin). Nếu gặp một đợt (các gói tin) ngắn, ít có khả năng bị loại bớt gói tin bởi vì hàng đợi chưa bị đầy thì bộ định tuyến không nên hủy bỏ những gói tin này một cách không cần thiết, bởi vì làm như thế sẽ tác động xấu đến hiệu suất của TCP. Dĩ nhiên, RED không thể tạm hoãn việc hủy bỏ vô thời hạn bởi vì một đợt dài sẽ làm đầy hàng đợi, kết quả chẳng khác nào chiến lược “cắt bớt phần đuôi”, và sẽ gây ra ảnh hưởng đến toàn bộ Internet.
3.2. Đánh giá qua mô phỏng hệ thống quản lý hàng đợi
Cơ chế điều khiển tắc nghẽn là một trong những vấn đề nghiên cứu chính của đánh giá hiệu năng mạng TCP/IP. Nhưng việc cài đặt thử nghiệm trên mạng đang hoạt động thực tế là khó thực hiện. Ở đây chúng tôi sử dụng phương pháp mô phỏng để đánh giá khả năng hoạt động của cơ chế quản lý RED trên mô hình đề xuất có nhiều nguồn đến tại nút mạng trung tâm với băng thông đường truyền không đối xứng. 
3.2.1. So sánh cơ chế DropTail và RED
Sử dụng NS-2 là công cụ mô phỏng mạng cài đặt trên hệ điều hành Linux [2]. Giả thiết mô hình thiết kế mạng mô phỏng được xây dựng như sau: 
Router
 S1
R2
Rec
2Mb/s, 20ms
2Mb/s, 20ms
10Mb/s, 2ms
10Mb/s, 2ms
Nơi gửi
Nơi nhận
Router
S5
R1
10M/2
10Mb/2
Exp
FTP
S6
FTP
Hình 2: Mô hình hệ thống mô phỏng
Hệ thống có 5 nguồn gởi tin S1 đến S5 theo dịch vụ FTP cài đặt TCP và 1 nguồn gửi tin S6 theo dịch vụ có cấu hình thay đổi tỷ suất truyền thích nghi (on/off) trên giao thức không yêu cầu báo nhận UDP. Bên nhận (Rec) được cài đặt giao thức giao vận TCP. Cơ chế điều khiển hàng đợi được tổ chức tại hàng đợi ra của Router (R1). Mô phỏng ứng dụng trong mạng có băng thông không đồng bộ giữa các cung truyền, đoạn từ R1(Router) đến R2 (Router) có băng thông 2Mb/s, độ trễ đường truyền là 20ms (tương ứng với tốc độ mạng WAN), băng thông các cung còn lại là 10Mb/s và độ trễ là 2ms (tương ứng với tốc độ của mạng LAN hiện tại).
Giới hạn hàng đợi tại các nút là 20 gói. Thứ tự mô phỏng tổ chức hàng đợi tràn ở các bộ định tuyến trung tâm. Đồng hồ TCP là 100ms. Quy luật dùng hàng đợi Drop Tail cho Router R2 và các trạm từ đầu cuối đến đầu cuối. Sử dụng hàng đợi RED tại đầu ra R1 (ngưỡng tối thiểu minth= 5, ngưỡng tối đa maxth= 15, = 0.002).
Qua quá trình theo dõi mô phỏng NS của mô hình trên, chúng tôi đã ghi lại toàn bộ hoạt động trong thời gian mô phỏng 20s, thời gian bắt đầu gửi của S1 đến S5 lần lượt cách nhau 0,1ms, kết quả ghi lại được phân tích bằng chương trình TRGRAPH dựa trên thư viện toán học Matlab để tính toán với kết quả như sau. 
Bảng 1: Bảng kết quả phân tích trên các mô hình
Mô hình
DropTail
RED(5/15)
RED(10/18)
RED(2/18)
Số gói tin gửi
Số gói tin rớt
Số gói tin mất
Độ trễ TB(ms)
18071
145
209
0.0566
18638
78
132
0.0569
19999
77
145
0.0600
19999
81
122
0.0567
Hình 3: Biểu đồ mô tả thông lượng của hệ thống cài đặt DropTail
Hình 4: Biểu đồ mô tả thông lượng của hệ thống có cài đặt RED
Qua kết quả thể hiện trên các hình 3, hình 4 với trục tung là thông lượng của hệ thống và trục hoành là thời gian mô phỏng, chúng ta thấy thông lượng ở mô hình có cài đặt RED ở R1 tăng lên rõ rệt ở thời điểm t=7s, t=10s và độ dao động của biểu đồ thông lượng ổn định ở các thời điểm có lượng gói tin đến vượt khả năng tiếp nhận của hàng đợi. Trên bảng 1 chúng ta thấy số gói tin rớt và mất giảm mạnh của RED (minth=5, maxth=15) so với cơ chế quản lý hàng đợi DropTail, cụ thể số gói tin rớt giảm 53,8% và số gói tin mất giảm 63,15%. Kết quả là thông lượng hệ thống sử dụng cơ chế RED ở những thời điểm ban đầu giảm nhưng sau đó tăng dần và ổn định hơn so với mô hình sử dụng hàng đợi DropTail. Đồng thời việc thay đổi giới hạn ngưỡng minth, maxth của cơ chế RED thì tỷ lệ gói tin rơi và mất thay đổi rất nhỏ. 
3.3.2. Ảnh hưởng của tham số hàng đợi đến sự rơi các gói tin tại nút mạng
Dựa trên mô hình đang xét, chúng tôi tiến hành khảo sát sự thay đổi tham số của cơ chế RED trong thời gian mô phỏng 5s. Kết quả thu được trên bảng 2 cho thấy tham số hàng đợi có ảnh hưởng rất lớn đến kết quả rơi các gói tin tại nút mạng. 
(RED)
0.005
0.004
0.003
0.002
0.0017
0.0015
0.001
0.0009
0.0005
0.0002
0.0001
Số gói tin rơi
34
35
29
22
18
18
14
16
14
10
7
Số gói tin được huyển
3567
3623
3718
3541
3628
3714
3806
3856
3904
3975
4053
Bảng 2: Kết quả đo được sau khi mô phỏng
Dựa vào bảng 2 ta xác định hàm tương quan giữa các tham số với số gói tin bị rơi và số gói tin đến R1. Trên cơ sở lý thuyết xác suất thống kê, chúng tôi tính được hệ số tương quan giữa tham số hàng đợi RED với số gói tin rơi là tương quan mạnh. 
Vì vậy việc cài đặt cơ chế quản lý hàng đợi RED có cơ chế điều khiển tự động tham số hàng đợi thích hợp với sự chuyển biến của các đợt bùng nổ thông tin trong thời gian dài tại những thời điểm lưu lượng gói tin đến nút mạng tăng nhanh là rất có ý nghĩa, đã làm ổn định lưu thông trên mạng khi có nhiều nguồn đến nút mạng đồng thời, đảm bảo thông lượng chung toàn hệ thống và hạn chế được gói tin rơi đáng kể.
4. Kết luận:
 Qua bài báo này chúng tôi đã nghiên cứu đựơc các phương pháp điều khiển lưu thông mạng một cách tích cực, xây dựng được mô hình mạng mô phỏng quá trình truyền dữ liệu kết hợp với cơ chế tránh tắc nghẽn. Với phương pháp quản lý hàng đợi RED, qua mô phỏng đã chứng minh được tính ưu việt hơn so với DropTail trong mô hình đã xét, đồng thời xác lập được mối tương quan giữa tham số hàng đợi với số gói tin rơi, có tác động mạnh đến quá trình điều khiển lưu thông trên mạng Internet. 
TÀI LIỆU THAM KHẢO
1. B. Suter et al., Efficient Active Queue Management for Internet Routers, Proc. Eng. Conf. at Interop 98, Las Vegas, NV (1998).
2. Http:// www. isi.edu/nsnam/ns/ns-documentation.html
3. M. Borden, V. Firoiu, Queue Management for Congestion Control, IEEE INFOCOM, (2000).
4. S. Floyd and V. Jacobson, Random Early Detection Gateways for Conges-tion Avoidance, IEEE/ACM Trans. Net., vol. 1, no. 4 (1993) 397 - 413.
5. Sally Floyd, A Report on Some Recent Developments in TCP Congestion Control, IEEE Magazine (2001).
TÓM TẮT
Trong bài báo này chúng tôi tập trung phân tích ảnh hưởng của các tham số trong cơ chế quản lý hàng đợi tích cực trên mô hình mạng Internet.
THE EFFECT OF PARAMETERS ON QUEUE MANAGEMENT AND CONGESTION AVOIDANCE ON INTERNET
Vo Thanh Tu
College of Sciences, Hue University
SUMMARY
 In this paper, we focus our study on analyzing the effects of parameters on active queue management schemes and congestion avoidance on Internet. 

File đính kèm:

  • docanh_huong_cua_cac_tham_so_trong_quan_ly_hang_doi_va_tranh_ta.doc