Cơ chế slow-start trong cỏc thuật toỏn Tahoe và Reno cú thể gõy ra mất rất nhiều gúi tin trước khi tỡm ra băng thụng phự hợp của kết nối. Trong trường hợp xấu nhất nú cú thể làm mất đễn một nửa cửa sổ hiện tại. Vegas cố gắng tỡm ra băng thụng phự hợp bằng cỏch so sỏnh hai loại thụng lượng tương tự như trờn. Để làm được điều này, cwnd được tăng gấp đụi trong một RTT, nhưng được giữ nguyờn trong RTT tiếp theo để so sỏnh, RTT tiếp theo lại tăng gấp đụi,.... Đến khi Actual cỏch Expected một khoảng nhỏ hơn , Vegas
sẽ thoỏt khỏi slow-start và chuyển sang giai đoạn CA. Tuy nhiờn [4] khụng đưa ra một giỏ trị cụ thể. Giỏ trị của cú thể chọn ở mức tương đương với
và .
1.7 Ƣu nhƣợc điểm và so sỏnh cỏc thuật toỏn
Tahoe cú ưu điểm là đơn giản và đạt hiệu quả hoạt động khỏ tốt. Do ra đời sớm nờn Tahoe đó được triển khai rộng rói trờn mạng. Nhược điểm của Tahoe là chưa tận dụng hết băng thụng trong giai đoạn tắc nghẽn do xử lớ chưa tốt. Reno khắc phục yếu điểm này của Tahoe bằng một sự điều chỉnh khỏ đơn giản, và đõy cũng chớnh là ưu điểm của Reno. Tuy nhiờn Reno chưa giải quyết triệt để được và hiệu quả hoạt động bị giảm xuống trong trường hợp nhiều gúi tin cựng bị mất trong một cửa sổ dữ liệu. Đõy cũng chớnh là một nhược điểm của Reno. NewReno thờm một sự điều chỉnh nhỏ vào Reno và khắc phục khỏ tốt yếu điểm này của Reno và điều này trở thành ưu điểm của NewReno. Nhược điểm của NewReno là vẫn chưa khắc phục được triệt để yếu điểm của Reno, dẫn đến hiệu quả hoạt động vẫn bị giảm sỳt trong một số tỡnh huống, đặc biệt là khi rất nhiều gúi tin trong một cửa sổ cựng bị mất. Tuy nhiờn nhược điểm của Reno và NewReno thường chỉ ảnh hưởng trong giai đoạn đầu của quỏ trỡnh truyền hoặc trong giai đoạn cú sự tăng đột biến mức dữ liệu tải lờn mạng, vỡ hầu như chỉ trong cỏc tỡnh huống này mới xảy ra mất nhiều gúi tin gần nhau.
Cỏc thuật toỏn trờn đều cú ưu và nhược điểm riờng, nhưng đều cú chung một nhược điểm là phải làm mất gúi tin trong giai đoạn khởi động thỡ mới tỡm được thụng lượng cho phộp và tiếp tục làm mất gúi tin trong quỏ trỡnh hoạt động. Sự giảm thụng lượng khi mất gúi tin khiến cho hoạt động của cỏc thuật toỏn này cú tớnh chu kỡ: tăng dần thụng lượng theo thời gian, đến một lỳc nào
đú vượt quỏ mức cho phộp dẫn đến mất gúi tin, thụng lượng bị giảm đi ớt nhất là một nửa, rồi lại tăng lờn và bắt đầu một chu kỡ mới. Đõy là nhược điểm cố hữu của cỏc thuật toỏn kiểu reactive.
Vegas thay đổi hẳn tớnh chất reactive của cỏc thuật toỏn trước nú, trở thành thuật toỏn cú tớnh proactive. Vegas dự đoỏn mức tắc nghẽn trờn mạng dựa vào sự so sỏnh thụng lượng mong muốn và thụng lượng thực tế, khiến cho nú cú thể giữ giai đoạn hoạt động CA trong một thời gian dài hơn. Điều này tạo sự ổn định trong quỏ trỡnh truyền dữ liệu. Mặt khỏc sự thay đổi cơ chế
slow-start trong Vegas tuy cú làm giai đoạn này kộo dài hơn một chỳt, nhưng làm cho Vegas cú thể dự đoỏn được thụng lượng cho phộp mà khụng cần làm mất gúi tin - một điều mà cỏc thuật toỏn trước đú hầu như khụng bao giờ đạt được. Cỏc thay đổi của Vegas khiến cho thụng lượng của nú tăng lờn 40-70% và tốc độ gúi tin mất giảm 2-5 lần so với Reno [4] khi hoạt động riờng rẽ. Nếu toàn bộ cỏc TCP trờn mạng hoạt động theo thuật toỏn Vegas, tắc nghẽn trờn cỏc nỳt mạng sẽ được giảm đi rất nhiều và thụng lượng của cỏc TCP sẽ ổn định hơn rất nhiều so với mạng dựng cỏc thuật toỏn khỏc.
Vegas cú hai nhược điểm chớnh được chỉ ra trong [19]. Nhược điểm thứ nhất nằm trong bản chất của một thuật toỏn dạng proactive, khiến cho nú luụn giữ thụng lượng sao cho khụng xảy ra mất gúi tin, dẫn đến thụng lượng đạt được thấp hơn một chỳt khi hoạt động cựng cỏc thuật toỏn reactive. [19] cho rằng Vegas chịu thiệt thũi hơn khi hoạt động cựng Reno. Điều này cú thể được hiểu đơn giản là vỡ mức độ tranh giành băng thụng chung của Reno mạnh hơn Vegas, Reno chấp nhận để cho mạng xảy ra tắc nghẽn - tức là mất gúi tin - thụng qua việc phỏt nhiều gúi tin, trong khi Vegas thỡ cố gắng khụng để xảy ra như vậy. Nhược điểm thứ hai nằm trong cơ chế sử dụng BaseRTT
kớch hoạt sau - cú BaseRTT cao hơn do mức tải dữ liệu lờn mạng cao hơn - cú khả năng chiếm được băng thụng cao hơn cỏc kết nối đang truyền tin trước đú [19].
CHƢƠNG 2
CÁC THUẬT TOÁN ĐIỀU KHIỂN TẮC NGHẼN MẠNG TRấN GATEWAY
Như đó đề cập trong chương 1, cú rất nhiều thuật toỏn điều khiển tắc nghẽn mạng được nghiờn cứu và triển khai trờn TCP, dựa trờn cơ chế điều khiển luồng của TCP. Nguyờn lớ chung của cỏc thuật toỏn đú là điều khiển lượng thụng tin đưa lờn mạng sao cho cú thể phự hợp nhất với khả năng truyền tin của mạng và do đú điều khiển được tắc nghẽn. Tuy nhiờn khả năng điều khiển tắc nghẽn bằng cỏc thuật toỏn này vẫn cũn gặp hạn chế, mà một hạn chế cơ bản là việc tổ chức hàng đợi tại cỏc Gateway khụng hợp lớ. Cơ chế quản lớ hàng đợi tớch cực, mà điển hỡnh là RED [18], đó khắc phục được nhiều yếu điểm của kiểu quản lớ hàng đợi DropTail [18] cổ điển và làm tăng khả năng điều khiển tắc nghẽn mạng.
Kiểu gateway DropTail với hàng đợi FIFO (hàng đợi vào trước ra trước) là kiểu đơn giản nhất và được triển khai tại hầu hết cỏc Gateway trờn mạng hiện nay. Hoạt động của hàng đợi FIFO trong gateway DropTail rất đơn giản. Chỳng sắp xếp cỏc gúi tin cần đưa tới lối ra theo thứ tự thời gian đến của gúi tin. Sau đú cỏc gúi tin sẽ lần lượt được đưa ra khỏi hàng đợi và được truyền đi. Gúi tin đến trước sẽ được truyền đi trước, gúi tin đến sau được truyền đi sau. Do kớch thước hữu hạn của bộ nhớ nờn sẽ xảy ra tỡnh huống hàng đợi bị đầy mà vẫn cú gúi tin đến. Khi đú gúi tin đến này sẽ bị loại bỏ, tức là sẽ phải được phỏt lại.
Chớnh vỡ việc loại bỏ cỏc gúi tin đến khi hàng đợi đó đầy gúp phần tạo nờn hiện tượng đồng bộ toàn cục (global synchronization). Khi hàng loạt gúi tin bị loại bỏ gần như đồng thời, dẫn đến việc hàng loạt TCP nhận được cảnh bỏo tắc nghẽn mạng gần như đồng thời, và chỳng gần như đồng thời giảm lượng tin truyền lờn mạng, dẫn đến lưu lượng trờn mạng giảm nhiều, hiệu suất do đú cũng bị giảm theo.
Theo lớ thuyết, để khụng loại bỏ gúi tin, kớch thước của hàng đợi phải tiến đến vụ cực trong trường hợp tổng tốc độ cỏc kết nối truyền tin đến lớn hơn so với tốc độ của kết nối truyền tin đi. Khả năng bộ nhớ vụ tận khụng bao giờ xảy ra, nờn việc mất gúi tin là tất yếu trờn mạng sử dụng Gateway kiểu DropTail. Kớch thước hàng đợi càng lớn thỡ khả năng loại bỏ gúi tin càng nhỏ và do đú thụng lượng trờn kết nối đi, hay hiệu suất sử dụng trờn kết nối đú càng tăng. Tuy nhiờn cỏc gúi tin sẽ phải chờ rất lõu trong hàng đợi trước khi được truyền đi, dẫn đến độ trễ trờn mạng tăng lờn. Độ trễ và thụng lượng đều là cỏc thụng số khi xem xột chất lượng dịch vụ. Vỡ vậy kĩ sư thiết kế mạng phải cõn nhắc và tỡm một sự thỏa hiệp phự hợp giữa hiệu suất và độ trễ tựy theo yờu cầu chất lượng dịch vụ mạng. Nếu là một mạng truyền thụng tin thoại, độ trễ khụng được quỏ cao. Nhưng nếu là một mạng truyền dữ liệu khỏc, cú thể hiệu suất lại quan trọng hơn độ trễ. Yờu cầu về một cơ chế quản lớ hàng đợi sao cho vừa cú thể đạt được hiệu suất cao mà độ trễ lại nhỏ ngày càng trở lờn cấp thiết khi mà yờu cầu về chất lượng dịch vụ, cả về thụng lượng và độ trễ ngày càng phỏt triển.
Cơ chế quản lớ hàng đợi tớch cực ra đời nhằm đỏp ứng yờu cầu trờn. Đó cú khỏ nhiều giải phỏp được đưa ra, trong đú RED là ứng viờn quan trọng nhất, đảm bảo được cả hai yờu cầu trờn. Ngày nay núi đến cơ chế quản lớ hàng đợi tớch cực là người ta nghĩ ngay tới RED. RED khắc phục được yếu điểm
của DropTail như hiện tượng đồng bộ toàn cục, độ trễ thấp, tớnh cụng bằng, v.v. Tuy nhiờn RED cũng cú những nhược điểm của nú, trong đú quan trọng nhất là sự nhạy cảm với cỏc thụng số, khiến cho việc lựa chọn thụng số cho phự hợp với điều kiện của mạng rất khú khăn và phức tạp. Cũng đó cú hàng loạt giải phỏp được đưa ra để khắc phục cỏc nhược điểm của RED, trong đú cú hai giải phỏp nổi bật là RED loại bỏ ưu tiờn và RED thớch nghi.