Giá trị delay của các luồng theo bandwidth

Một phần của tài liệu (LUẬN VĂN THẠC SĨ) Đánh giá yêu cầu tài nguyên mạng của ứng dụng Video Conference Luận văn ThS. Công nghệ thông tin (Trang 75)

Hình 4.5. Độ trễ trung bình của từng luồng theo bandwidth

Khi thay đổi băng thông các đường truyền (trừ đường truyền nối nút S0 và S1 được giữ không thay đổi trong tất cả các mô phỏng =150Kbps) thì độ trễ trung bình các gói tin của luồng TCP thay đổi không đáng kể. Độ trễ trung bình các gói tin của luồng voice và video giảm dần và xấp xỉ bằng nhau.

Điều này có thể được giải thích như sau: Khi banwidth có giá trị nhỏ nhất là 500kbps, tổng lưu lượng đưa vào mạng của luồng video và voice là 384kbps +19.2kbps = 403.2kbps. Phần băng thông của các đường truyền (trừ đường truyền S0-S1) còn có thể sử dụng được là 96.8kbps, trong khi đó luồng TCP có

khả năng tự thích ứng với đường truyền và đã bị hạn chế tốc độ tối đa đưa dữ liệu vào mạng là 150kbps, do đó độ trễ tăng lên cao hơn không nhiều, so với các trường hợp bandwidth được thiết lập các giá trị lớn hơn.

Luồng voice và video có độ trễ xấp xỉ như nhau và khi tăng bandwidth đến mức 600 trở lên thì delay của voice và video xấp xỉ bằng nhau.

Để so sánh thông lượng trung bình của các luồng khi băng thông thay đổi ta dựa vào bảng 4.2 và hình 4.6 sau đây:

Link Bandwidth (Kbps) Throughput (Kbps) TCP (S0 > S2) Video (S1 >S11) Voice (S1 > S11) 500 100.08048701 357.986025190 17.696321565 600 145.95820106 375.083085826 18.9369580165 700 145.98955815 375.193099897 18.9432989690 800 146.01308862 375.193099897 18.9432989690 900 146.03139364 375.193099897 18.9432989690 1000 146.04604097 375.193099897 18.9432989690 Bảng 4.2. Thông lượng trung bình của các luồng theo băng thông

Throughput của luồng voice là không đổi, giữ ở mức ~ 10Kbps. Luồng TCP throughput gần đạt được đến mức 150Kbps

Luồng video throughput gần đạt đến mức 380Kbps

Để kiểm tra tỷ lệ mất gói tin của các luồng khi băng thông thay đổi ta dựa vào bảng 4.3 và hình 4.7 sau: Link Bandwidth (Kbps) Throughput (Kbps) TCP (S0 > S2) Video (S1 >S11) Voice (S1 > S11) 500 7.75193798449613 4.01441070509522 7.1428571428571 600 9.42408376963351 0 0 700 9.42408376963351 0 0 800 9.42408376963351 0 0 900 9.42408376963351 0 0 1000 9.42408376963351 0 0

Bảng 4.3. Tỷ lệ mất gói tin của các luồng theo băng thông

Theo đồ thị trên ta thấy với bandwidth = 500kbps, lossrate của luồng video khoảng 4%, luồng voice khoảng 7.14%, luồng TCP khoảng 7.75%.

Khi ta tăng băng thông đến giá trị 600kbps trở lên lossrate của luồng video và voice là 0%, tỷ lệ mất gói của luồng TCP là giữ ở mức 9.4%. Điều này có thể giải thích là do đặt băng thông cho luồng TCP là 150Kbps nên mặc dù tăng kích thước của đường truyền lên 600, 700, 800, 900, 1000 thì tỷ lệ mất gói của luồng TCP là không đổi

Từ các kết quả trên có thể nhận xét như sau:

Khi banwidth có giá trị nhỏ nhất là 500kbps, tổng lưu lượng đưa vào mạng của luồng video và voice là xấp xỉ 400kbps (đã được tính ở trên), lưu lượng luồng TCP tối đa có thể đạt là 150kbps. Như vậy, tổng lưu lượng đưa vào mạng có thể vượt quá bandwidth của các đường truyền. Vì vậy, hàng đợi ở đầu vào đường truyền nối nút mạng S1 và S2 thường xuyên đầy, dẫn đến độ trễ trung bình của các gói tin thuộc các luồng đi qua chặng này cao và có thể có biến động trễ lớn hơn, so với các trường hợp bandwidth lớn hơn. Ngoài ra tỉ lệ mất gói tin là đáng kể.

Khi banwidth có giá trị từ 600kbps trở lên, tổng lưu lượng đưa vào mạng của tất cả các luồng trong mọi thời điểm đều không thể vượt quá 550kbps (400kbps+150kbps), tức là luôn nhỏ hơn năng lực vận chuyển của các đường truyền. Vì vậy, hàng đợi ở đầu vào đường truyền nối nút mạng S1 và S2 thường xuyên ngắn và không bao giờ đầy, dẫn đến độ trễ trung bình của các gói tin thuộc các luồng đi qua chặng này thấp và không có biến động trễ lớn. Ngoài ra, tỉ lệ mất gói tin là xấp xỉ bằng 0.

Kết luận về yêu cầu tài nguyên đối với ứng dụng video conference: Trong mọi thời điểm hoạt động của ứng dụng video conference, chất lượng dịch vụ chỉ có thể được đảm bảo nếu phần băng thông có thể sử dụng được cho ứng dụng này lớn hơn từ 10% trở lên so với lưu lượng sinh ra bởi ứng dụng.

4.2.2. Thực nghiệm 2 mô phỏng mô hình IntServ

Hình 4.8. Cấu hình mô phỏng mạng thực nghiệm 2.

Thực nghiệm 2: Mô phỏng mạng IP có hỗ trợ việc đặt trƣớc tài nguyên

Để thực hiện mô phỏng 2 thì cần có các tập lệnh để thực hiện kỹ thuật lưu lượng và các mô hình khôi phục, bảo vệ đường mà thư viện ns-2.32 không có, do vậy tôi đã sử dụng phiên bản MNSv2.0 tại website http://flower.ce.cnu.ac.kr/~fog1/mns/index.html và thực hiện biên dịch lại các tham số đường dẫn biến môi trường của MNSv2.0 để tương thích với ns-2.32.

Thiết lập cấu hình mô phỏng: Topo mạng như hình 4.7. trong đó node 0 và node 10 là router thông thường, các node từ 1 đến 9 là các router hỗ trợ RSVP tạo thành một miền IntServ.

Các nguồn sinh lưu lượng được gắn vào node R0, các đích nhận lưu lượng được gắn vào node 10. Mỗi nguồn phát lưu lượng với tốc độ 0,8Mbps, kích thước gói 600B. Các luồng lưu lượng đều được truyền theo tuyến tường minh ER (Explicit Routing) định trước.

Thực hiện và phân tích kết quả mô phỏng:

- Thời điểm 0,5s: Luồng 1 truyền trên LSP_1100 (1-3-5-7-9) - Thời điểm 1,0s: Luồng 2 truyền trên LSP_1200 (1-2-4-6-8-9) - Thời điểm 1,5s: Luồng 3 truyền trên LSP_1300 (1-3-4-6-5-7-8-9) - Thời điểm 5s cả ba luồng ngưng truyền.

Hình 4.9. Hình ảnh luồng dữ liệu trong mô phỏng 2

Kết quả:

- Luồng 1 đã truyền 749 gói, mất 0 gói, tỷ lệ mất gói là 0% - Luồng 2 đã truyền 666 gói, mất 0 gói, tỷ lệ mất gói là 0% - Luồng 3 đã truyền 583 gói, mất 0 gói, tỷ lệ mất gói là 0%

Hình 4.10. Lưu lượng các luồng trong mô phỏng 2

Nhận xét:

Để thiết lập một luồng dự trữ trước tài nguyên, trước tiên bên gửi phát một bản tin Path dọc theo tuyến tường minh ER. Bản tin Path chứa một session-id và các yêu cầu băng thông. Khi bản tin Path tới đích, bên nhận đáp ứng bằng một bản tin Resv. Bản tin Resv được truyền theo hướng ngược lại với bản tin Path bằng cách dùng thông tin của hop kề trước trong bản tin Path, nó cũng chứa cùng session-id như bản tin Path tương ứng. Bản tin Resv sẽ thiết lập việc giữ trước tài nguyên ở các router, khi bản tin Resv tới đích thì quá trình thiết lập dự trữ tài nguyên hoàn thành.

sau cùng theo tuyến 1-3-4-6-5-7-8-9. Như vậy cả 3 luồng lưu lượng được phát theo 3 đường truyền riêng nên việc thiết lập đặt trước tài nguyên của cả 3 luồng đều thành công. Kết quả mô phỏng của tôi đã chỉ ra rằng, các tham số QoS đều nằm trong phạm vi yêu cầu, tỷ lệ mất gói tin trên các luồng là 0%

4.2.3. Đánh giá yêu cầu tài nguyên mạng theo mô hình DifServ

Thiết lập tô-pô mạng mô phỏng

Hình 4.11. Topo mạng mô phỏng mô hình DiffServ

Thiết lập kịch bản mô phỏng

Mạng có 21 nút, có 6 router và 15 máy chủ được triển khai. Đường truyền giữa các nút đều là full-duplex, không có lỗi.

Với mô hình này ta có thể làm nổi bật hành vi chuyển tiếp của DiffServ đối với các loại lưu lượng khác nhau (VoiceIP, Video, FPT)

Router biên DiffServ kết nối với các các router có các loại lưu lượng khác nhau có giao diện vào như bảng dưới. Bộ lập lịch WRR được chọn trong suốt quá trình mô phỏng.

Kiểu lưu Lượng PHB DSCP Bộ đo

VoiIP EF 10 Token bucket, CIR

64kbps, CBS 1k byte

Video EF 20 Token bucket, CIR

384kbps, CBS 10k byte

FTP AF 30 Token bucket, CIR

100kbps, CBS 1k byte

Khác Mặc định 40

Token bucket, CIR 700kbps, CBS 100k

byte Bảng 4.4. TCS cho giao diện vào e1 Nguồn sinh lưu lượng

- Nguồn sinh lưu lượng voice: sử dụng nguồn phát CBR (Constant Bit Rate) chạy tại các nút Server Voice. Nguồn CBR sử dụng thực thể giao vận UDP để phát tin với tốc độ không đổi 19.2 Kbps tới thực thể null bên nút nhận Client Voice.

- Nguồn sinh lưu lượng video: sử dụng nguồn phát CBR (Constant Bit Rate) chạy tại các nút Server Video. Nguồn CBR sử dụng thực thể giao vận UDP để phát tin với tốc độ không đổi 384 Kbps tới thực thể null bên nút nhận Client Video.

- Nguồn sinh lưu lượng data: sử dụng nguồn phát FTP (mô phỏng dịch vụ truyền tệp) chạy tại các nút Server FTP. Nguồn FTP sử dụng thực thể giao vận TCP để phát tin tới thực thể sink (nhận và gửi trả lại ACK) bên nút nhận Client FTP.

- Ngoài ra để quá trình mô phỏng giống thực tế, trong mạng DiffServ còn tạo ra có các lưu lượng nền khác từ các mạng ngoài DiffServ, truyền theo kiểu cố gắng tối đa. Do lưu lượng nguồn FTP có cơ chế truyền theo kiểu thích nghi nên trong mô phỏng này ta sử dụng nguồn phát FTP để tạo ra các lưu lượng cố gắng tối đa.

Chạy mô phỏng, kết xuất và biểu diễn kết quả

Tiến hành mô phỏng trong trường hợp sử dụng và không sử dụng DiffServ với các điều kiện giống nhau. Trong cả hai trường hợp, mô phỏng được tiến hành trong khoảng thời gian 50s. Tại thời điểm 0.1 các nguồn FTP, CBR bắt đầu phát tin vào đường truyền. Đến thời điểm 50s, tất cả các nguồn đầu ngừng phát.

Do các nguồn voice đều có các tham số cấu hình giống nhau nên ta chỉ so sánh độ trễ và thông lượng của một nguồn trong hai trường hợp sử dụng và không sử dụng DiffServ. Tương tự với nguồn video ta cũng làm như vậy.

Kết quả mô phỏng :

Hình 4.12. So sánh độ trễ trung bình của nguồn video

Từ hình 4.13 chúng ta thấy với nguồn video, khi không áp dụng Diffserv, độ trễ của các gói tin biến thiên chủ yếu trong miền từ 90ms đến 112ms. Chiến lược Diffserv giúp cải thiện đáng kể giá trị độ trễ này. Cụ thể, độ trễ của các gói tin chỉ biến thiên chủ yếu trong miền từ 85ms đến 97ms. Bên cạnh việc giảm một cách đáng kể thời gian trễ của các gói tin thì khi áp dụng Diffserv, thông lượng nguồn video đạt được cũng đạt một giá trị khá cao.

Hình 4.13. So sánh độ trễ trung bình của nguồn voice

Nhìn trên đồ thị ta thấy nguồn voice khi không áp dụng DiffServ có độ trễ cao hơn so với việc áp dụng DiffServ. Như vậy việc áp dụng DiffServ vừa đảm bảo được các ràng buộc về thời gian truyền tin đồng thời tạo thuận lợi cho việc thiết lập các tham số nhằm khử jitter ở phía nhận.

Hình 4.15. So sánh thông lượng trung bình của nguồn video

Bên cạnh việc giảm một cách đáng kể thời gian trễ của các gói tin thì khi áp dụng DiffServ, thông lượng nguồn voice đạt được trong hình 4.14 cũng đạt một giá trị khá cao và ổn định hơn, dải biến thiên cũng hẹp hơn so với việc không sử dụng DiffServ.

4.3. Kết luận

Trong chương này luận văn đã tìm hiểu về bộ mô phỏng NS-2, đây là là phần mềm mô phỏng mạng theo phương thức điều khiển sự kiện rời rạc và hướng đối tượng. Luận văn cũng đã sử dụng bộ mô phỏng NS-2 để mô phỏng, từ đó rút ra các đánh giá, nhận xét, so sánh thông lượng, băng thông, tỉ lệ mất gói tin của mô hình mạng thông thường khi băng thông thay đổi. Mô phỏng được mạng khi áp dụng mô hình IntServ, DiffServ. Đánh giá và so sánh độ trễ , thông lượng trung bình giữa mạng thông thường với mạng sử dụng mô hình DiffServ.

Từ các kết quả ở trên, chúng ta thấy rằng, đối với mô hình IntServ khi áp dụng các cơ chế phân luồng cho từng luồng dữ liệu thì tỉ lệ mất gói tin của các luồng là 0%, có đủ băng thông yêu cầu cho các CR-LSP. Như vậy, với mô hình IntServ hiệu quả sử dụng tài nguyên mạng được nâng cao

Đối với mô hình DiffServ cho ứng dụng Video Conference thì thời gian trễ của các gói tin được giảm đáng kể, đồng thời thông lượng cũng đạt giá trị tốt hơn, ổn định hơn nhiều so với mạng thông thường.

KẾT LUẬN

Luận văn đã trình bày các kiến thức về truyền thông đa phương tiện và ứng dụng của Video Conference. Luận văn cũng đã tìm hiểu và trình bày các cơ chế làm tăng chất lượng dịch vụ cho ứng dụng truyền thông đa phương tiện, phân tích và đưa ra được những nhược điểm của mạng IP với dịch vụ cố gắng tối đa, trình bày một số kỹ thuật nén audio, nén video

Luận văn đã giới thiệu tổng quan về đảm bảo chất lượng dịch vụ cũng như về hai mô hình IntServ và DiffServ. Các mô hình DiffServ và IntServ rất có hiệu quả trong việc đảm bảo chất lượng dịch vụ truyền thông đa phương tiện. Tuỳ vào yêu cầu cũng như đặc điểm của mạng mà ta có thể xây dựng các mô hình với các thông số thích hợp. Mô hình IntServ đòi hỏi phải có sự đặt trước tài nguyên ở tất các router mà dịch vụ truyền thông đa phương tiện truyền các lưu lượng qua nên khó thực hiện nhưng có hiệu quả cao. Mô hình DiffServ không yêu cầu đặt trước tài nguyên nên tương đối đơn giản, nhưng hiệu quả hạn chế hơn so với mô hình IntServ.

Luận văn đi sâu về trình bày chi tiết về các thành phần của hai mô hình IntServ và DiffServ. Cuối cùng luận văn trình bày các mô phỏng về hai mô hình này, đưa ra các đánh giá về hiệu năng của các mô hình, so sánh với trường hợp mạng thông thường, không áp dụng mô hình IntServ và DiffServ. Các kết quả mô phỏng cho thấy nếu mạng áp dụng mô hình IntServ hoặc DiffServ thì hiệu năng mạng sẽ tốt hơn mô hình mạng thông thường. Điều này là phù hợp với những đánh giá về mặt lý thuyết.

Do thời gian có hạn nên luận văn không thể tránh khỏi những hạn chế và thiếu sót nhất định. Việc mô phỏng các mô hình còn khá khiêm tốn, chưa tiến hành mô phỏng được hết các khả năng của IntServ và DiffServ. Nếu điều kiện cho phép, tôi sẽ nghiên cứu các khả năng đó trong thời gian tới.

CÁC HƢỚNG NGHIÊN CỨU TIẾP THEO

Trên cơ sở đã đạt được, học viên dự kiến sẽ nghiên cứu các vấn đề sau với công cụ NS2:

- Tích hợp kết nối lưu lượng giữa hai mô hình IntServ và DiffServ trong truyền thông đa phương tiện đảm bảo chất lượng dịch vụ.

- Nghiên cứu tính hợp và mô phỏng IntServ và DiffServ vào mạng chuyển mạch nhãn MPLS. Đặc biệt là giao thức RSVP-TE dùng để giữ trước tài nguyên trong chuyển mạch nhãn.

TÀI LIỆU THAM KHẢO A. Tài liệu Tiếng Việt

1. Nguyễn Đình Việt (2008), bài giảng “Đánh giá hiệu năng mạng máy tính”.

2. Nguyễn Đình Việt, bài giảng “Truyền dữ liệu và mạng máy tính nâng cao. 3. Vũ Duy Lợi, Nguyễn Văn Vỵ, “Về đảm bảo chất lượng dịch vụ trên Internet”. 4. Vũ Hồng Sơn, Nguyễn Văn Dũng, Ngô Quang Thuận, “Đảm bảo chất lượng dịch vụ trên mạng IP bằng phương pháp Diffserv”.

5. Nguyễn Hứa Duy Khang, “Giới thiệu các phần mềm dùng kết hợp với ns-2”

B. Tài liệu Tiếng Anh

5. L.C.Wolf, C.Griwadz and R.Steinmetz (1997), Multimedia communication,

Proc. of the IEEE, vol.85, pp.1915-1933, Dec. 1997.

6. Kun I.Pack (2005), QoS in Packet Network, The MITE Coporation USA, Springer 2005. Print ISBN: 0-387-23389-X.

7. R. Braden, D. Clark and S. Shenker, Integrated Services in the Internet Architecture: an Overview, RFC1633, June 1994.

8. Junseok Hwang (1996), A Market-Based Model for the Bandwidth Management of IntServ-DiffServ QoS Interconnection: A Network Economic Approach, M.S. University of Colorado.

9. Mario Marchese (2007), QoS over Heteroigeneous Networks. 10. The ns Manual, January 20, 2007, the VINT Project. 11. Jae Chung and Mark Claypool, NS by Example.

12. Giovanni Perbellini (2005), Network advanced modeling in NS-2.

13. http://www.cisco.com/en/US/docs/internetworking/technology/handbook/QoS.html

Một phần của tài liệu (LUẬN VĂN THẠC SĨ) Đánh giá yêu cầu tài nguyên mạng của ứng dụng Video Conference Luận văn ThS. Công nghệ thông tin (Trang 75)

Tải bản đầy đủ (PDF)

(89 trang)