Chất lượng của TCP trong môi trường không dây thấp hơn mạng có dây. Nguyên nhân chính của việc này là do TCP không nhận ra được chính xác nguyên nhân gây mất gói mà tất cả quy về là do tắc nghẽn trong mạng. Trong khi đó, việc mất gói trong môi trường không dây không chỉ là do tắc nghẽn mà còn có thể là lỗi đường truyền.
Gói dữ liệu TCP cũng có thể mất nếu chất lượng môi trường truyền thấp, tầng liên kết (link layer) không có một giao thức điều khiển có độ tin cậy cao. Sau một số lần cố gắng truyền lại, tầng liên kết chuyển giao việc xử lý lỗi cho TCP. Tình trạng chuyển giao (handover) kết nối cũng có thể gây ra tình trạng mất dữ liệu, và có thể mất dữ liệu trong cả cửa sổ phát. Việc mất dữ liệu do giao thức tầng liên kết không tin cậy hay handover có thể gây ra tình trạng timeout dẫn đến TCP phải quay về pha slow-start; hoặc đầu phát nhận được ba gói ACK trùng lặp kết quả là dẫn đến việc thực hiện Fast-Recovery và Fast- Retransmit. Trong một số trường hợp, TCP thực thi cơ chế tránh tắc nghẽn không cần thiết. Sau khi xảy ra tình trạng mất gói, chất lượng môi trường truyền có thể phục hồi trạng thái tốt rất nhanh chóng, hoặc sau khi handover việc truyền thông giữ thiết bị và BS không gặp phải vấn đề gì.
Nếu độ trễ đường truyền đủ dài, gây ra tình trạng timeout ở đầu phát. Kết quả là kích hoạt việc truyền lại không cần thiết. Độ trễ đường truyền gây ra do nhiều nguyên nhân: băng thông thấp, tầng liên kết hoạt động không tốt, môi trường truyền không tốt hoặc do các bộ đệm chờ xử lý ở các thiết bị trung gian. Đồng thời, độ trễ lớn cũng làm cho RTO tăng cao. Kết quả là TCP phản ứng chậm chạp khi mất dữ liệu thật sự.
Kết luận
Như vậy theo một khảo sát nghiên cứu [6], vấn đề của các giải thuật TCP truyền thống mắc phải trong môi trường không dây là:
• Việc mất gói trên đường truyền không dây mà nguyên nhân là do môi trường truyền không tốt, do mất kết nối tạm thời, do di chuyển … Trong tất cả các trường hợp này, TCP đều phản ứng như trong trường hợp tắc nghẽn. Để tối ưu hóa TCP, trong hoặc
o Cải tiến TCP có khả năng phân biệt nguyên nhân mất gói.
o Có phương thức hoạt động hợp lý trong trường hợp mất gói không phải do tắc nghẽn.
• Độ trễ cao làm TCP hoạt động không hiệu quả, giải pháp đưa ra là cố gắng tối ưu hóa độ trễ, tránh việc tăng RTT không cần thiết. Giải pháp cho vấn đề này thông thường là các giải pháp hỗ trợ tầng liên kết hoặc tính băng thông hợp lý thay cho việc giảm cửa sổ phát một cách không có căn cứ.
• Đảm bảo độ công bằng trong cải tiến giải thuật (fairness)
Chương 3. Một số phương pháp nâng cao hiệu năng TCP trong mạng không dây
Có nhiều cách tiếp cận để nâng cao hiệu năng của TCP, và được chia làm bốn nhóm chính: giải pháp ở tầng liên kết dữ liệu (link layer), giải pháp chia kết nối, giải pháp thông báo tường minh (explicit notification), và giải pháp đầu cuối (end-to-end).
Hình 3.1 Lược đồ phân loại các giải pháp tối ưu hóa TCP trong môi trường không dây 3.1. Link layer
Ý tưởng chính là nâng cao khả năng TCP bằng cách hỗ trợ ở lớp data link bên dưới. Thay vì sử dụng phương thức hoạt động truyền lại end-to-end tại tầng giao vận của TCP, phương pháp này áp dụng việc truyền lại cục bộ ở tầng link. Khi hoạt động trong môi trường lỗi nhiều như môi trường không dây, việc truyền lại từng chặng tại tầng data link giúp tránh được việc phải truyền lại dữ liệu trên một quãng đường dài.
3.1.1. Snoop
Snoop sử dụng cơ chế truyền lại của tầng link để nâng cao độ tin cậy cho mạng không dây tránh cho TCP phải truyền lại không cần thiết. Snoop thực thi như là một agent (tác tử) trong một BS. Snoop đệm lại các frame ở tầng liên kết và xem xét nội dung của TCP header mà không cần TCP phải được thực thi trong BS. Việc truyền lại thông qua kết nối không dây được kích hoạt ở BS nếu xảy ra timeout ở tầng liên kết hoặc nhận được các dupACKs từ MH. Khi dupACKs đầu tiên đến, BS tiến hành truyền lại. Khi những dupACKs khác đến, BS hủy các dupACKs này để ngăn đầu phát không thực thi Fast- Recovery và Fast-Retransmit trong khi tầng link đang thực thi truyền lại.
Hình 3.2 Mô hình mạng không dây với BS đóng vai trò Snoop
Snoop quản lý luồng dữ liệu từ FH đến MH thông qua việc đệm lại những gói TCP chưa được xác nhận (ACK) và thực thi truyền lại cục bộ dựa trên hai tiến trình: Snoop_ACK() và Snoop_Data(). Đối với luồng dữ liệu từ MH đến FH, snoop phát hiện gói mất và áp dụng cơ chế NACK.
Hình 3.3 Lưu đồ Snoop xử lý nhận dữ liệu từ FH tại BS
Hình 3.4 Lưu đồ Snoop xử lý khi nhận ACK từ MH tại BS
Bằng thí nghiệm mô phỏng [6], người ta đã chứng minh Snoop cho phép TCP hoạt động với throughput lớn hơn, đồng nghĩa với TCP hoạt động với hiệu năng cao hơn.
3.1.2. WTCP
WTCP cung cấp cơ chế trung gian cho điều khiển TCP. Với WTCP, hai đầu cuối là FH và MH không phải thay đổi giao thức, mà chỉ cần thay đổi ở BS. Ý tưởng chính của WTCP giống với Snoop là WTCP đóng vai trò trung gian, nhớ đệm gói lại chờ xử lý.
Khi nhận được gói gửi đến từ FH, WTCP kiểm tra số tuần sự của TCP header (sequence number – seq_no). Nếu seq_no theo thứ tự mong đợi, WTCP tăng lượng byte đã nhận được (pkt_size), đồng thời tăng số tự seq_no mong đợi. Dữ liệu vừa nhận được được đưa vào bộ đệm và thời gian đến (arrival time) được ghi nhận lại – cơ chế stamptime. Trong trường hợp seq_no lớn hơn mong đợi (do mất dữ liệu trên đường truyền), dữ liệu đến cũng được ghi nhận thời gian và lưu lại trong bộ đệm, nhưng seq_no mong đợi vẫn được giữ nguyên. Nếu seq_no nhỏ hơn mong đợi, gói được bỏ qua. Cơ chế xử lý gói khi nhận được minh họa bởi lưu đồ giải thuật sau:
Hình 3.6 Lưu đồ WTCP xử lý khi nhận dữ liệu
WTCP sau khi đệm các gói song song với việc gửi các đến MH. WTCP thực thi một cách độc lập với cơ chế điều khiển luồng không dây. WTCP vẫn duy trì các thông tin cho kết nối không dây như: cửa sổ truyền (transmission window), sequence number và sequence number của của ACK cuối cùng từ MH. WTCP truyền các gói đệm trong buffer (bộ đệm ) trong khoảng t_window (có thể xem t_window là cửa sổ phát của WTCP). Mỗi gói khi được gửi đến MH (kể cả truyền lại) đều được tính lại stamptime bằng cách cộng thời gian được đánh dấu hiện tại với lượng thời gian mà gói được chứa trong bô đệm (residence- time). Khi một segment được gửi cho MH, BS tính lại thời gian timeout nếu không có quá trình tính timeout nào đang chờ xử lý (pending). Lưu đồ giải thuật cho việc phát gói WTCP:
Hình 3.7 Lưu đồ WTCP chuyển tiếp gói
Cơ chế timestamp và tính lại timestamp cho phép WTCP tính toán chính xác RTT và loại bỏ khoảng thời gian delay. BS chỉ xác nhận một segment tới FH khi MH đã xác nhận segment. Tùy thuộc vào timeout hay dupACKs mà BS có cơ chế truyền lại khác nhau. Trong trường hợp timeout, cửa sổ phát chỉ còn là 1 segment, và WTCP hoạt động ở trạng thái gọi là “bad state”. Khi đã được xác nhận, WTCP trở về trạng thái “good state” với cửa sổ phát bằng cửa sổ quảng bá ở đầu nhận (awnd).
Hình 3.8 Lưu đồ WTCP xử lý khi nhận ACK
3.1.3. Kết luận
Mục tiêu của nhóm giải pháp này là sử dụng việc truyền lại ở tầng liên kết và cơ chế đệm gói ở BS để giảm thiểu số lượng gói bị mất trong truyền thông giữa FH và MH. Điều khó khăn khi thực hiện phương pháp này là tất cả các gói dữ liệu gửi và xác nhận đều phải thông qua cùng một BS (hoặc một thiết bị trung gian sử dụng cách tiếp cận này). Mặt khác, với Snoop và WTCP, base station đòi hỏi phải biết được thông tin ở TCP Header với việc thừa nhận rằng, mỗi TCP segment đều phải được đóng gói trong một frame của tầng link. Điều này thường xảy ra trong WLAN nhưng không phải cho tất cả các mạng không dây khác. Nếu khung dữ liệu của tầng liên kết sử dụng thông qua giao diện sóng radio không đủ lớn để đóng gói một segment, thường trong mạng WWAN, thì Snoop và WTCP không thể thực hiện chức năng của mình. Trong trường hợp luồng dữ liệu được mã hóa bởi các cơ chế bảo mật như Ipsec, việc đọc được header của TCP ở một thiết bị trung gian là không thể thực hiện được.
Một điểm khá quan trọng nữa của các giải thuật nhóm này là ngay trong cơ chế đệm gói (lõi của giải thuật). Trong các thuật giải trên, một segment chỉ được xóa khỏi bộ đệm khi được xác nhận. Như vậy, nếu có nhiều luồng dữ liệu cùng đi qua BS, BS cần một lượng
lớn bộ nhớ để lưu trữ. Trong khi đó, ngay trong thuật toán không có cơ chế nào dành cho quản lý bộ đệm một cách hiệu quả.
3.2. Chia kết nối
Ý tưởng chính của nhóm giải thuật này là chia kết nối thành hai phần riêng biệt. Khi đó, kết nối ban đầu được chia thành hai kết nối thông qua một nốt mạng trung gian. Giải pháp này có phần giống với phương pháp hỗ trợ link layer, chỉ khác là các xử lý được thực hiện ở tầng TCP.
Hình 3.9 Mô hình chia kết nối
3.2.1. Indirect TCP (I-TCP)
I-TCP đề xuất chia kết nối từ một MH đến một thiết bị FH thành hai kết nối riêng biệt: một kết nối giữa MH và một thiết bị định tuyến hỗ trợ di động (mobile support router – MSR) thông qua kết nối không dây và kết nối còn lại giữa MSR đến FH trong mạng có dây. MSR trong trường hợp này tương ứng với một BS, hay nói cách khác là BS có tích hợp MSR. Việc chia kết nối giúp tách biệt hai môi trường truyền dẫn với những đặc tính khác nhau là không dây và có dây. Từ đó, dễ dàng hơn cho việc giải quyết vấn đề từng kết nối một cách độc lập. Ở tầng giao vận (transport), việc chia kết nối mang lại những lợi ích như:
• Tách biệt chức năng điều khiển luồng và điều khiển tắc nghẽn trên môi trường không dây với môi trường truyền có dây. Việc chia tách này xuất phát từ sự khác nhau về đặc điểm giữa hai môi trường truyền. Với môi trường có dây, các kết nối ethernet hay ATM cho phép đường truyền nhanh, băng thông lớn và tin cậy trong khi đó, đường truyền không dây chậm và dễ xảy ra lỗi do nhiễu tín hiệu (fading hay tỉ lệ lỗi cao).
• Trên phần kết nối qua mạng không dây, cho phép nhận biết chính xác nguyên nhân của các sự kiện mất gói tin như: mất kết nối do lỗi đường truyền, do nút mạng di chuyển hay những đặc điểm khác của kết nối không dây.
• I-TCP cho phép BS (có hỗ trợ MSR) quản lý số lượng lớn hơn các kết nối giữa FH và MH. BS có thể đóng vai trò như một proxy đại diện cho MH thực thi các giao thức phức tạp, đơn giản hóa các thao tác cho MH trong trường hợp MH chỉ là các thiết bị đơn giản.
Hình 3.10 Mô hình I-TCP
Khi một MH cần liên lạc với FH sử dụng I-TCP, yêu cầu được gửi đến MSR để để mở kết nối. MSR khi nhận được yêu cầu thiết lập kết nối từ MH, sẽ tạo kết nối với FH tương ứng.
Hình 3.11 BS đóng vai trò như Proxy trong I-TCP
MSR đóng vai trò như một proxy, mở cùng lúc 2 kết nối thông qua hai socket. Khi MH di chuyển, MSR đóng vài trò điều khiển quá trình handoff và chuyển các thông tin sang MSR mới.
Hình 3.12 Quá trình xử lý chuyển vùng (handoff) của I-TCP
Trong ví dụ trên, MH đầu tiên thiết lập kết nối với FH thông qua MSR-1 và di chuyển sang vị trí thuộc vùng phủ sóng của MSR-2. Khi MH yêu cầu kết nối I-TCP với FH trong vùng MSR-1, MSR-1 thiết lập một socket cho MH (MH socket) để quản lý kết nối với MH và socket cho FH (MH socket) để quản lý kết nối với MH. Khi MH di chuyển vào vùng MSR-2, trạng thái kết nối của I-TCP ở MSR-1 được chuyển sang MSR-2. MSR-2 tạo hai socket đáp ứng với kết nối I-TCP với cùng tham số mà MSR-1 đã thiết lập. Khi kết nối các đầu cuối đã được thiết lập thành phần cố định của kết nối (FH) I-TCP không thay đổi khi FH di chuyển, do đó không cần phải thực hiện kết nối lại với MSR mới. Điều này đảm bảo kết nối TCP hoàn toàn trong suốt với FH.
Giải pháp chia đôi kết nối của I-TCP là làm mất đi ngữ nghĩa end-to-end của TCP, nghĩa là, thực thể gửi gói tin biên nhận có thể không phải là thực thể nhận TCP (ở đầu thu). Hầu hết các ứng dụng sử dụng TCP để truyền dữ liệu như ftp hay một số ứng dụng khác đều có cơ chế khôi phục khi lỗi. Tuy nhiên đối với I-TCP, các ứng dụng không thể thực hiện chức năng trên một cách hiệu quả do không thật sự biết dữ liệu đã truyền đến đích hay chưa. Đồng thời I-TCP không có cơ chế nào cảnh báo lên tầng ứng dụng. Do đó, các ứng dụng dựa trên I-TCP phụ thuộc nhiều vào MSR cũng như kết nối giữa MSR và MH.
Quá trình handoff được thực hiện như sau:[6]
2. Tiến trình mhmicp thiết lập MSR mới thành bộ định tuyến mặc định và gửi thông điệp chào (greeting) đến MSR chứa các kết nối I-TCP hiện tại và địa chỉ của MSR cũ (MSR-1).
3. Tiến trình msrmicp ở MSR-2 gửi xác nhận cho thông điệp greeting từ MH (grack) 4. Tiến trình msrmicp (cần chọn chỗ nào thích hợp giải thích từ viết tắt này và ý
nghĩa của vấn đề liên quan) tại MSR-2 gửi thông điệp “MHIn” tới I-TCP daemon cục bộ chứa danh sách của các kết nối I-TCP nhận được từ MH
5. I-TCP deamon thiết lập socket cho cả kết nối trên mạng không dây và mạng có dây và chuẩn bị yêu cầu I-TCP handoff cho MSR-1. Deamon gửi ACK đến msrmicp. 6. Msrmicp gửi một gửi con trỏ (forwarding pointer) đến MSR-1, thông báo cho
MSR-1 biết MSR nào sẽ quản lý MH 7. Msrmicp tại MSR-1 xác nhận (ACK)
8. Msrmicp tại MSR-1 gửi thông điệp MHOut đến deamon của nó với địa chỉ của MH đã di chuyển ra ngoài để thông báo MH đã di chuyển ra ngoài.
9. Khi nhận thông điệp MHOut, I-TCP deamon đóng băng tất cả các kết nối liên quan tới MH. Đồng thời gửi thông điệp yêu cầu handoff đến deamon của MSR-2 để đảm bảo rằng đã sẵn sàng và gửi trạng thái của các kết nối I-TCP sang MSR-2 (MHState)
1. I-TCP deamon tại MSR-2 nhận trạng thái kết nối đồng thời khởi động lại từng kết nối. Sau đó, gửi ACK cho MSR-1 thông báo hoàn tất quá trình handoff (Ack).
Hình 3.13 Các bước thực hiện trong quá trình handoff của I-TCP
3.2.2. Kết luận
Việc chia kết nối mang lại nhiều lợi ích như tránh mất dữ liệu trong quá trình handover (hay handoff); Đồng thời, giúp giảm lượng dữ liệu bị mất trong quá trình truyền và tăng hiệu quả của kết nối như đã trình bày ở trên. Tuy nhiên, việc chia kết nối cũng mang lại những bất cập. Thứ nhất, tất cả các dữ liệu phải đi qua cùng một BS. Thứ hai, TCP header phải đọc được bởi BS (MSR), do đó, với các kênh truyền sử dụng các cơ chế bảo mật như IPSec, I-TCP không thể hoạt động. Ngoài ra, I-TCP không còn mang đúng ý nghĩa là kết nối end-to-end. I-TCP thích hợp với WLAN có sử dụng Mobile IP.
3.3. Cơ chế cảnh báo tường minh EN (Explicit Nofitication)
TCP thông thường luôn cho rằng việc mất dữ liệu trên đường truyền là do tắc nghẽn trên