môi trƣờng mạng NGN toàn IP
Trọng tâm của phần này là khả năng ứng dụng của các phƣơng pháp phản hồi tắc nghẽn tại bộ định tuyến trong môi trƣờng mạng NGN toàn IP. Phần này giới thiệu khả năng và bằng cách nào các phƣơng pháp này có thể đƣợc triển khai (một cách dần dần) vào mạng NGN toàn IP để cải thiện hoạt động của
mạng. Ngoài ra, còn giải thích khả năng và bằng cách nào các phƣơng pháp phản hồi tắc nghẽn tại bộ định tuyến này có thể giải quyết với các cơ chế bảo mật của IPSec [18, 19].
Các khía cạnh tiếp theo đƣợc xem xét là:
- Một vài trong số các phƣơng pháp phản hồi tắc nghẽn yêu cầu các thuộc tính và có sự thay đổi trong các bộ định tuyến và/hoặc các hệ thống đầu cuối. Những yêu cầu nào có thể đƣợc đáp ứng dễ dàng, và những yêu cầu nào thì khó có thể đƣợc thực hiện trong môi trƣờng mạng hiện nay. Khía cạnh này cũng bao gồm xem xét mức độ phức tạp của phƣơng pháp phản hồi tắc nghẽn yêu cầu tại các bộ định tuyến và/hoặc hệ thống đầu cuối
- Có thể triển khai các phƣơng pháp phản hồi chống tắc nghẽn dần dần trong môi trƣờng mạng hiện nay đƣợc hay không. Nếu có thì phải xem xét thêm các nội dung sau:
+ Mức độ ảnh hƣởng trong việc tăng hiệu năng mong muốn của phƣơng pháp điều khiển nếu chỉ một vài bộ định tuyến đƣợc trang bị chức năng phản hồi tắc nghẽn.
+ Đối với một phƣơng pháp phản hồi tắc nghẽn, cần xem xét chiến lƣợc nào đƣợc sử dụng để lựa chọn các bộ định tuyến đƣợc trang bị trƣớc tiên các chức năng phản hồi tắc nghẽn mới của phƣơng pháp phản hồi tắc nghẽn đó.
+ Ngoài ra, xem xét phƣơng pháp phản hồi tắc nghẽn nào phù hợp với triển khai trên một phần của mạng, ví dụ mạng của một nhà cung cấp, nhằm cải thiện khả năng điều khiển tắc nghẽn ít nhất là trong các phần mạng này.
Một khía cạnh đáng quan tâm khác là liệu và bằng cách nào một phƣơng pháp phản hồi chống tắc nghẽn có thể giải quyết các cơ chế bảo mật đang tồn tại, ví dụ cơ chế bảo mật IPSec. Trong IPSec, có hai chế độ hoạt động khác nhau:
+ Trong chế độ truyền thông (transport mode) của IPsec, phần tải của gói tin IP đƣợc mã hoá. Chế độ này cung cấp một sự truyền tải bảo mật giữa hai hệ thống đầu cuối. Trong trƣờng hợp này, các bộ định tuyến trung gian không thể đọc hoặc ghi các trƣờng trong phần tiêu đề TCP.
+ Trong chế độ đƣờng hầm (tunnel mode) của IPsec, toàn bộ gói tin IP đƣợc mã hoá nhƣ tải của một gói tin IP mới. Chế độ này cung cấp một cơ chế truyền tải bảo mật của các gói IP giữa hai bộ định tuyến. Trong trƣờng hợp này, một bộ định tuyến trung gian không thể xác định đƣợc có bao nhiêu luồng gói
khác nhau đƣợc truyền trong một đƣờng hầm. Ngoài ra, các bộ định tuyến trung gian lại không thể đọc hoặc ghi các trƣờng trong phần tiêu đề TCP đƣợc truyền tải trong các luồng IP.
4.3.1. (F)EWA
(F)EWA có thể chỉ có thể làm việc nếu các phân đoạn TCP và các báo nhận TCP đi qua cùng các bộ định tuyến có khả năng (F)EWA trong mạng. Vì vậy, cả hai phƣơng pháp này chỉ có thể triển khai trong môi trƣờng mạng hiện tại nếu các gói tin IP đƣợc định tuyến đối xứng trong mạng. Bộ định tuyến có khả năng (F)EWA cần phải có khả năng giảm cửa sổ nhận thông báo trong báo nhận TCP để thông báo đến phía gửi TCP về trọng tải hiện tại của bộ định tuyến. Vì vậy, (F)EWA không thể đƣợc triển khai trên mạng Internet hiện tại nếu các kết nối TCP đƣợc mã hoá sử dụng chế độ truyền IPSec.
Ƣu điểm chính của (F)EWA đƣợc so sánh với các phƣơng pháp phản hồi tắc nghẽn tại bộ định tuyến khác là (F)EWA có thể đƣợc triển khai từng bƣớc trên mạng. Nếu triển khai thành công, tức là, các bộ định tuyến có hiện tƣợng thắt cổ chai trong mạng đƣợc trang bị ban đầu có khả năng (F)EWA, thì hiệu năng mong muốn tăng lên của (F)EWA sẽ không bị giảm đi. Ngoài ra, mức độ phức tạp của thuật toán (F)EWA trong các bộ định tuyến thấp, có thể so sánh với XCP.
4.3.2. ETCP
Khả năng ứng dụng của ETCP phụ thuộc vào việc triển khai của (F)EWA trong tất cả các bộ định tuyến hoặc tối thiểu là tại bộ định tuyến thắt cổ chai trên mạng. Vì vậy, khả năng ứng dụng của (F)EWA trong các bộ định tuyến IP hiện nay và sự truyền tải thông tin điều khiển tắc nghẽn của (F)EWA từ các bộ định tuyến đến các hệ thống đầu cuối đều có giá trị cho ETCP.
Một nhƣợc điểm của ETCP phiên bản hiện nay so với các phƣơng pháp khác (ví dụ QS-TCP) là phía gửi có khả năng ETCP không thể kiểm tra liệu các bộ định tuyến trên mạng có đƣợc trang bị khả năng (F)EWA hay không. Vì vậy không thể triển khai ETCP ở phía gửi trong mạng nếu không phải tất cả bộ định tuyến thắt cổ chai đƣợc trang bị (F)EWA. Nhƣng với các cơ chế tƣơng tự nhƣ sử dụng trong QS-TCP thì nó có thể cung cấp cho phía gửi ETCP các đặc điểm để phát hiện liệu các bộ định tuyến có đƣợc trang bị các khả năng (F)EWA và có chấp nhận cửa sổ nhận thông báo mới nằm trong báo nhận TCP hay không.
Do ETCP đòi hỏi các thay đổi nhỏ nhƣng cơ bản trong thuật toán điều khiển chống tắc nghẽn của phía gửi TCP, khó để có thể triển khai một cách toàn
diện phƣơng pháp phản hồi tắc nghẽn tại bộ định tuyến này trong các mạng trên cơ sở IP hiện nay. Nhƣng phía gửi TCP có thể đƣợc cập nhật dần dần các chức năng mới sau khi tất cả các bộ định tuyến trong mạng đƣợc trang bị FEWA.
4.3.3. XCP
Mặc dù XCP là một trong các phƣơng pháp hứa hẹn nhất trong số các phƣơng pháp phản hồi tắc nghẽn tại bộ định tuyến nhƣng sự triển khai của XCP trong các mạng trên cơ sở IP hiện nay gặp khó khăn, bởi vì các hệ thống đầu cuối và các bộ định tuyến cần phải đƣợc trang bị các thuật toán điều khiển tắc nghẽn mới XCP. Đặc biệt, độ phức tạp của các thuật toán điều khiển tắc nghẽn XCP trong các bộ định tuyến dƣờng nhƣ cao hơn so với các phƣơng pháp phản hồi tắc nghẽn tại bộ định tuyến khác.
Về lý thuyết, XCP có thể đƣợc triển khai một cách hoàn toàn trong mạng trên cơ sở IP. Hai trƣờng hợp cần phải phân biệt là:
- Một vài bộ định tuyến và phía nhận không có khả năng XCP
- Một sự đan xen của các kết nối XCP và non-XCP cùng tồn tại trong mạng.
Trong trƣờng hợp đầu tiên, phía gửi XCP cần phải kiểm tra xem tất cả các bộ định tuyến và phía nhận có khả năng XCP. Điều này có thể đƣợc thực hiện bằng cách sử dụng các cơ chế TCP và IP đang tồn tại. Nếu ít nhất một trong số các bộ định tuyến không có khả năng XCP thì phía gửi không thể sử dụng giao thức XCP và phải chuyển sang một giao thức truyền tải thích hợp nhƣ TCP. Đối với trƣờng hợp thứ hai, một bộ định tuyến có khả năng XCP có thể điều khiển khá tốt cả hai loại lƣu lƣợng. Để làm đƣợc điều đó một bộ định tuyến có khả năng XCP cần phải phân biệt giữa lƣu lƣợng XCP và lƣu lƣợng non-XCP và xếp hàng chúng riêng biệt. Sau đó các gói tin trong cả hai hàng đợi đƣợc xử lý sao cho các luồng XCP từ một hàng đợi đạt đƣợc băng thông trung bình nhƣ là các luồng non-XCP từ hàng đợi kia. Vì vậy, việc triển khai dần dần XCP trong môi trƣờng các mạng trên cơ sở IP hiện nay vẫn còn là một vấn đề thách thức.
Chú ý rằng, chất lƣợng việc triển khai dần dần của XCP là khác với việc triển khai dần dần của (F)EWA. Ví dụ, nếu ít nhất một bộ định tuyến trên tuyến truyền dẫn không có khả năng XCP thì XCP không thể đƣợc sử dụng và ƣu điểm hoạt động so với TCP chuẩn bị mất hoàn toàn. Ngƣợc lại, nếu một số bộ định tuyến trên đƣờng không có khả năng (F)EWA thì hiệu năng của F(EWA) so với TCP chuẩn vẫn có thể đƣợc duy trì nếu ít nhất các bộ định tuyến thắt cổ chai trên tuyến truyền dẫn đƣợc trang bị (F)EWA. Vì vậy, hiệu năng của XCP
trên mạng chỉ có thể đạt đƣợc nếu phần lớn các bộ định tuyến và các điểm đầu cuối đƣợc triển khai giải thuật XCP.
XCP sử dụng thêm một tiêu đề chống tắc nghẽn mang thông tin điều khiển tắc nghẽn từ phía gửi XCP đến các bộ định tuyến có khả năng XCP và thông tin phản hồi tắc nghẽn theo hƣớng ngƣợc lại. Nếu tiêu đề chống tắc nghẽn này đƣợc phân biệt với dữ liệu trong giao thức truyền tải và loại trừ mã hoá của dữ liệu giao thức truyền tải (chế độ truyền tải IPSec) thì XCP không bị ảnh hƣởng bởi tất cả các cơ chế bảo mật lớp truyền tải trong các mạng trên cơ sở IP hiện nay. Nhƣng XCP không thể sử dụng với chế độ IPSec đƣờng hầm (IPsec tunnel).
4.3.4. CSFQ
CSFQ đƣợc phát triển để cải thiện độ công bằng giữa các luồng lƣu lƣợng trong mạng hoặc phần mạng các bộ định tuyến có khả năng CSFQ. Vì vậy có thể triển khai từ từ CSFQ trong các mạng trên cơ sở IP. Tuy nhiên, CSFQ không cung cấp thông tin phản hồi tắc nghẽn rõ ràng từ bộ định tuyến để cải thiện hơn nữa hiệu năng của các luồng lƣu lƣợng từ đầu cuối – đầu cuối. Nhƣ vậy, khả năng sử dụng của phƣơng pháp này có một số giới hạn.
Nhƣợc điểm chính của phƣơng pháp CSFQ so sánh với các phƣơng pháp phản hồi tắc nghẽn tại bộ định tuyến khác là các bộ định tuyến biên của miên CSFQ cần lƣu trữ trạng thái của luồng để xác định các luồng, để đo tốc độ luồng hiện tại và để đánh dấu các gói tin của luồng theo tốc độ luồng hiện tại đo đƣợc. Vì vậy, khả năng mở rộng và khả năng ứng dụng của CSFQ bị hạn chế đối với các phần mạng có một phần nhỏ của luồng lƣu lƣợng đi qua bộ định tuyến biên.
Việc xác định một luồng dữ liệu tại một bộ định tuyến biên có thể phức tạp hoặc thậm chí bị ngăn cản nếu các lƣu lƣợng đi vào miền CSFQ đƣợc mã hóa. Ví dụ, nếu các luồng đƣợc mã hóa IPSec thì các bộ định tuyến ở biên sẽ không thể phân biệt các luồng này. Vì vậy, bộ định tuyến ở biên chỉ có thể xác định tốc độ kết hợp các luồng lớp truyền tải giữa hai điểm đầu cuối. Vì vậy, có thể có các kiểu luồng lƣu lƣợng khác nhau tồn tại trong miền CSFQ và trƣờng hợp này không đƣợc các nhà phát triển CSFQ xem xét đến.
Tóm lại, phƣơng pháp CSFQ không thể sử dụng đối với các luồng lƣu lƣợng đƣợc mã hóa bởi IPSec.
4.3.5. FBA-TCP
Vì FBA –TCP là phƣơng pháp mở rộng của CSFQ, cung cấp thông tin phản hồi rõ từ miền CSFQ để cải thiện điều khiển tắc nghẽn của ngƣời gửi TCP.
Vì vậy, các đặc tính và giới hạn của CSFQ đều đúng với FBA –TCP. Thêm vào đó, khi thông tin phản hồi rõ từ miền CSFQ đƣợc truyền dẫn tới phía nhận TCP, phƣơng pháp FBA-TCP không thể cùng hoạt động với chế độ mã hóa IPSec đƣờng hầm.
4.3.6. QS-TCP
Phƣơng pháp QS-TCP không xác định bất kỳ giải thuật nào tại các bộ định tuyến mà chỉ có một số nguyên tắc và quy định thiết kế chung đƣợc đƣa ra. Nhƣng có thể giả sử rằng độ phức tạp ứng dụng của QS-TCP trong các bộ định tuyến là có thể so sánh đƣợc với (F)EWA.
QS-TCP là không trong suốt với các hệ thống đầu cuối. Nó đòi hỏi các thay đổi nhỏ hơn ở phía nhận TCP và các thay đổi lớn ở phía gửi. Vì vậy, việc triển khai QS-TCP trên mạng trên cơ sở IP hiện nay là khó khăn hơn so với các phƣơng pháp khác (ví dụ (F)EWA). Và hiệu năng tăng lên mong muốn của QS- TCP cũng hạn chế hơn so với các phƣơng pháp phản hồi tắc nghẽn khác do QS- TCP chỉ sử dụng trong pha bắt đầu của kết nối TCP với một cửa sổ tắc nghẽn khởi tạo lớn hơn trƣờng hợp TCP chuẩn. Ngoài ra, việc triển khai dần dần của QS-TCP trong mạng cũng có các hạn chế có thể so sánh về khả năng sử dụng và hiệu năng mong muốn so với việc triển khai dần dần của XCP.
QS-TCP có khả năng hoạt động cùng với cơ chế bảo mật IPSec trong chế độ truyền tải IPsec. Nhƣng QS-TCP không thể hoạt động cùng với các luồng IP đƣợc mã hóa trong chế độ mã hóa IPSec đƣờng hầm.