Phƣơng án cải tiến DCTCP

Trong giải thuật DCTCP, bên gửi điều chỉnh cửa sổ gửi dần dần, tùy theo trạng thái tắc nghẽn ở switch. Các luồng lớn truyền trong thời gian dài sẽ chiếm băng thông của đƣờng truyền và khi các luồng mới gia nhập thì vì trạng thái thay đổi dần dần (Steady State) nên chúng sẽ đƣợc chia sẻ băng thông dần dần, dẫn đến thời gian truyền có thể lâu hơn.

Sở dĩ có trạng thái dần dần này là vì tham số để điều chỉnh cửa sổ tắc nghẽn αđƣợc tính theo công thức: α = (1-g)α + gF trong đó g là trọng số có giá trị g = 1/16. Khi có tình trạng tắc nghẽn xảy ra hay không đều ảnh hƣởng chậm đến α nên giá trị α thay đổi dần dần.

Các luồng lớn truyền trong thời gian dài sẽ chiếm băng thông của đƣờng truyền và chia sẻ dần dần với các luồng mới tham gia vào đƣờng truyền dẫn đến thời gian truyền của luồng có thể tăng lên, nhất là các luồng nhỏ. Để khắc phục hạn chế này của giải thuật DCTCP ta cần có sự ƣu tiên khác nhau giữa các luồng để chúng có thể nhanh chóng nhận đƣợc phần băng thông của đƣờng truyền.

Trƣớc khi đƣa ra phƣơng án cải tiến giải thuật DCTCP, ta xem xét một giải thuật khác đã đƣợc trình bày, dựa trên DCTCP là D2TCP [Deadline-Aware Datacenter TCP (D2TCP)] nhƣng có thêm yếu tố độ ƣu tiên của luồng.

3.1.1 Giải thuật D2TCP

Độ ƣu tiên của luồng đƣợc xác định tùy thuộc vào luồng có yêu cầu thời gian deadline không. Thời gian deadline là khoảng thời gian lớn nhất mà luồng phải truyền xong.

 Với các luồng nhỏ yêu cầu thời gian deadline thì chỉ số ƣu tiên d > 1.

 Với các luồng nhỏ không yêu cầu thời gian deadline hoặc các luồng lớn không yêu cầu thời gian deadline chỉ số ƣu tiên d ≤ 1.

Giá trị của d đƣợc xác định trong khoảng (1/n, n) với n là số nguyên dƣơng.

Cũng giống nhƣ DCTCP, giải thuật D2TCP tính toán giá trị α là ƣớc lƣợng xác suất hàng đợi của switch vƣợt ngƣỡng là: α = (1-g)α + gF. Và khi có tắc nghẽn thì sẽ giảm cửa sổ gửi đi theo công thức:

cwnd = cwnd (1- /2)

Khi d ≤ 1 thì giá trị lớn hơn so với α và khi d > 1 thì giá trị nhỏ hơn so với α.

Hình 16 – D2TCP

Nhƣ vậy đối với các luồng nhỏ yêu cầu thời gian deadline thì khi có tắc nghẽn trong mạng thì tốc độ gửi tin của nó (cửa sổ tắc nghẽn CWND) có thể giữ nguyên hoặc

giảm đi không đáng kể. Còn các luồng lớn hoặc các luồng nhỏ không yêu cầu thời gian deadline thì khi có tắc nghẽn, tốc độ gửi tin của chúng giảm nhiều hơn và chia sẻ băng thông đƣờng truyền nhiều hơn.

Giải thuật D2TCP ƣu việt hơn so với DCTCP ở chỗ nó xác định rõ độ ƣu tiên của các luồng, từ đó các luồng có độ ƣu tiên cao hơn sẽ nhận đƣợc nhiều băng thông hơn và giảm thời gian truyền. Tuy nhiên để đạt đƣợc điều này thì D2TCP yêu cầu không chỉ là sự thay đổi ở tầng giao vận và yêu cầu hỗ trợ ECN của các switch mà còn thay đổi ở tầng ứng dụng, đòi hỏi các lập trình viên phải khai báo thêm tham số đối với các luồng yêu cầu thời gian deadline. Đây là điều không mong muốn khi phải thay đổi quá nhiều thứ, dẫn đến phức tạp khi triển khai, ứng dụng mặc dù đem lại những hiệu quả nhất định.

Điều mà ta mong muốn đó là thay đổi các thành phần của kiến trúc, môi trƣờng càng ít càng tốt mà vẫn đạt đƣợc mục đích. DCTCP là giải thuật điển hình, đáng chú ý trong môi trƣờng Data Center mà đem lại hiệu quả ƣu việt hơn so với giải thuật TCP thông thƣờng. Vì vậy, ta xem xét phƣơng án cải tiến giải thuật DCTCP ở tầng giao vận mà không tác động thêm các thành phần khác nữa.

Nhƣ đã trình bày ở trên, trong giải thuật DCTCP cần có sự ƣu tiên giữa các luồng sao cho các luồng lớn đã truyền trong thời gian dài cần giảm tốc độ gửi nhiều hơn để nhƣờng băng thông cho các luồng mới, đặc biệt là các luồng nhỏ bởi vì chúng thƣờng yêu cầu thời gian truyền thấp. Tuy nhiên, ta không thể biết đƣợc một luồng mới tham gia là luồng nhỏ hay luồng lớn mà không có thông tin cung cấp thêm bởi lập trình viên – điều này ta không mong muốn vì đòi hỏi phải tác động đến tầng ứng dụng. Vì vậy, có một giải pháp đó là khi một luồng mới bắt đầu tham gia truyền, ta xem luồng đó là luồng nhỏ và tạo điều kiện băng thông cho nó truyền trong một khoảng thời gian ngắn t0. Bởi vì các luồng nhỏ sẽ kết thúc quá trình truyền trong thời gian ngắn nên sau khoảng thời gian ƣu tiên t0 đấy, nếu luồng đó thực sự là luồng nhỏ thì ta đã ƣu tiên cho nó còn nếu đó là luồng lớn thì bắt đầu từ thời điểm đấy nó sẽ không đƣợc ƣu tiên khi truyền nữa.

3.1.2 Giải thuật DCTCP-F

Giải thuật DCTCP-F dựa trên ý tƣởng của giải thuật DCTCP là phản ứng với mức độ của tắc nghẽn và chú trọng vào cải tiến khả năng chia sẻ băng thông giữa các luồng (Fair Sharing).

Tƣơng tự nhƣ giải thuật DCTCP, Sender luôn ƣớc lƣợng tỷ lệ gói tin bị đánh dấu là

α. Giá trị α đƣợc cập nhật sau mỗi khoảng thời gian 1 RTT nhƣ sau: α ← (1 – g)α +gF

Trong đó F là tỷ lệ gói tin bị đánh dấu CE trong khoảng thời gian 1 RTT trƣớc đó. Giá trị g thuộc khoảng (0,1) là trọng số mang ý nghĩa ảnh hƣởng của F lên giá trị mới của α. Ý nghĩa của giá trị α là ƣớc lƣợng xác suất mà mạng bị tắc nghẽn.

Dựa trên ý tƣởng về hàm gamma αd

với d là chỉ số ƣu tiên nhƣ D2TCP, trong giải thuật DCTCP cũng đƣa ra khái niệm độ ƣu tiên p (viết tắt của Priority) cho luồng và đƣợc xác định nhƣ sau:

 Trong khoảng thời gian t0 ban đầu thì luồng có độ ƣu tiên p = pmax > 1

 Sau khoảng thời gian t0 đó thì độ ƣu tiên của luồng giảm dần cho đến pmin> 0

Ta xác định t0nhƣ sau: (adsbygoogle = window.adsbygoogle || []).push({});

Theo thống kê trong môi trƣờng Data Center [Data Center TCP (DCTCP), SIGCOMM 2010] thì các luồng nhỏ yêu cầu độ trễ thấp có size từ 2KB đến 100KB, các luồng lớn là các luồng có size từ 1MB đến 100MB. Nhƣ vậy t0 thời điểm mà luồng đã truyền đƣợc 100KB dữ liệu.

Hình 17 - Sự phụ thuộc của độ ƣu tiên của luồng theo kích cỡ luồng

Khi luồng bắt đầu truyền đƣợc từ 0 đến 100KB dữ liệu thì độ ƣu tiên p đạt cực đại

pmax, sau đó thì độ ƣu tiên giảm dần và đến khi luồng đã truyền đƣợc 1MB dữ liệu thì độ ƣu tiên đạt cực tiểu pmin . Khi kích cỡ của luồng trong khoảng (100KB, 1MB) thì độ ƣu tiên của luồng giảm tuyến tính từ pmax đến pmin, cụ thể đƣợc tính theo công thức:

p = pmin + ( pmax - pmin )( 1000 - pmin ) / 900

Xét hàm gamma f = αp có đồ thị nhƣ hình vẽ, trong đó giá trị p chỉ độ ƣu tiên của luồng. Ta có biểu diễn của hàm f:

Hình 18 - Hàm gamma f = αp

Dựa vào hình vẽ, ta có nhận xét:

- Khi α dần đến 0 (hoặc 1) thì giá trị của f = αp cũng dần đến 0 (hoặc 1). - Khi α thuộc khoảng (0 , 1) thì

o Với p > 1 thì giá trị αp << α. o Với p = 1 thì giá trị αp = α. o Với p < 1 thì giá trị αp >> α

Khi nhận đƣợc gói tin ACK với cờ ECE, thay vì giảm cửa sổ tắc nghẽn theo giá trị

α nhƣ DCTCP, thì với giải thuật mới này, Sender sẽ giảm cửa sổ tắc nghẽn theo giá trị f = αpnhƣ sau:

cwnd = (1 – α/2)cwnd Để đơn giản trong việc tính toán giá trị của hàm mũ f = αp

, ta sử dụng xấp xỉ Bernoulli với αϵ (0,1) nhƣ sau:

( ) ( ( )) ( ) Hình vẽ biểu diễn hàm f = αp

và xấp xỉ của nó trên đồ thị với một vài trƣờng hợp của p. Ta nhận thấy hàm xấp xỉ cho kết quả gần đúng và sai số có thể giảm thiểu bằng cách mở rộng khoảng (pmin, pmax).

Hình 19 - Xấp xỉ Bernoulli (vẽ bằng công cụ tại www.grapsketch.com) Hình vẽ biểu diễn hàm f = αp

Nhƣ vậy, khi luồng có độ ƣu tiên cao (giá trị p lớn) thì giá trị giảm của cửa sổ tắc nghẽn nhỏ và khi luồng có độ ƣu tiên thấp (giá trị p nhỏ) thì giá trị giảm của cửa sổ tắc nghẽn sẽ lớn.

Hình 20 - Minh họa giải thuật đề xuất

Khi một luồng mới bắt đầu quá trình truyền, trong khoảng thời gian t0 ban đầu, nó sẽ tự cho mình là luồng nhỏ có độ ƣu tiên p đạt cực đại pmax và khi xảy ra tắc nghẽn tại switch (chiều dài hài đợi vƣợt quá ngƣỡng K) thì luồng mới này sẽ nhận đƣợc gói tin ACK với cờ ECE và giảm cửa sổ tắc nghẽn đi rất ít. Trong khoảng thời gian này, luồng sẽ nhanh chóng đƣợc chia sẻ phần băng thông của đƣờng truyền.

Sau khoảng thời gian t0 này, nếu luồng đã kết thúc quá trình truyền thì luồng đó thực sự là luồng nhỏ và đã đƣợc ƣu tiên trong quá trình truyền. Nếu luồng vẫn tiếp tục truyền thì trạng thái của luồng chuyển dần dần từ luồng nhỏ sang luồng lớn và lúc này độ ƣu tiên p của luồng giảm dần về pmin. Trong khoảng thời gian này, khi xảy ra tắc nghẽn thì luồng sẽ giảm cửa sổ tắc nghẽn đi nhiều hơn và nhận đƣợc phần băng thông của đƣờng truyền ít hơn.

Các giá trị biên của p là pmax và pmax cũng ảnh hƣởng đến thông lƣợng truyền tải (throughput). Bởi vì nếu giá trị pmin nhỏ quá thì các luồng lớn có thể giảm cửa sổ gửi nhiều quá dẫn đến băng thông không đƣợc tận dụng. Nếu pmax lớn quá dẫn đến các luồng nhỏ đƣợc ƣu tiên nhiều quá nên khi tắc nghẽn chúng giảm quá ít buộc các luồng lớn khác giảm quá nhiều nên thông lƣợng cũng bị giảm.

3.1.3 Giải thuật đề xuất DCTCP-FA

Ta gọi giải thuật đề xuất là DCTCP-FA bởi vì nó dựa trên tƣ tƣởng của giải thuật DCTCP-F là phản ứng với mức độ của tắc nghẽn và chú trọng vào cải tiến khả năng chia sẻ băng thông giữa các luồng. Tuy nhiên điểm khác biệt ở đây là việc tính toán giá trị pmax và pmin.

Lấy ý tƣởng từ WRED, xác định giá trị K theo các lớp traffic với các thông số DSCP khác nhau. Nhằm liên hệ với độ ƣu tiên lớp 3, nên pmax sẽ đƣợc tính theo giá trị dscp: (adsbygoogle = window.adsbygoogle || []).push({});

pmax = dscp/8

Và đƣợclàm tròn pmax = pmax + 1, để tránh trƣờng hợp có giá trị bằng 0.

Giá trị pmin sẽ đƣợc xác định:

pmin = dscp * 1/n Với n đƣợc chọn sao cho pmin < 1.

Hình 21 – DCTCP-F

Nhƣ vậy luồng nào đƣợc ƣu tiên lớp 3 với DSCP cao sẽ có pmax cao, lúc này f = αp

sẽ gần giá trị 0, và cwnd sẽ giao động nhỏ.

Và sau khi chuyển sang long lives thì luồng nào có ƣu tiên DSCP thấp sẽ có pmin

thấp, lúc này f = αp

sẽ gần giá trị 1, độ dao động cwnd lớn hơn (nhƣ TCP thông thƣờng).

3.2 Kết luận

Trong chƣơng 3 ta đã điểm qua các phƣơng án cải tiến DCTCP, và đƣa ra giải thuật đề xuất mới DCTCP-FA. Với ý tƣởng từ DCTCP-F, để xây dựng một giải thuật mới với sự liên hệ của độ ƣu tiên luồng với giá trị DSCP lớp 3. Trong chƣơng tiếp theo, ta sẽ đƣa ra các thực nghiệm mô phỏng các giải thuật.

CHƢƠNG 4 : THỰC NGHIỆM ĐÁNH GIÁ GIẢI THUẬT DCTCP 4.1 Xử lý TCP trong nhân Linux

Trong phần Networking của nhân Linux thì có 2 cấu trúc dữ liệu luôn đƣợc sử dụng: sock để duy trì trạng thái của một kết nối và sk_buff để lƣu trữ dữ liệu và trạng thái của các gói tin đến và gói tin đi.

Hầu hết mã nguồn của giải thuật TCP nằm ở thƣ mục net/ipv4. Các file header có thể tìm thấy ở thƣ mục include/linux và include/net. Giải thuật quản lý tắc nghẽn chủ yếu nằm ở các file sau:

 tcp_input.c : làm nhiệm vụ xử lí khi có các gói tin đến.  tcp_output.c: làm nhiệm vụ xử lí khi cần gửi các gói tin đi.  tcp.h: khai báo các biến, hằng số

Hình 22 – Sơ đồ xử lý TCP trong nhân Linux

Khi có gói tin gửi đến từ tầng IP, hàm ip_local_delivery() đƣợc gọi để thực hiện các thủ tục TCP. Giao thức tƣơng ứng với gói tin đƣợc xác định và gọi hàm xử lí tƣơng ứng. Với IPv4 thì tƣơng ứng với hàm tcp_v4_rcv() và gọi tcp_v4_do_rcv().

Tùy theo trạng thái của kết nối mà hàm tƣơng ứng đƣợc gọi. Ở trạng thái đã thiết lập kết nối (TCP_ESTABLISHED) thì hàm tcp_rcv_established() đƣợc gọi. Hàm này sẽ thực hiện các bƣớc sau:

 B1: Kiểm tra checksum của gói tin, nếu không đúng thì bỏ qua.

 B2: Kiểm tra số thứ tự của gói tin, nếu không đúng thứ tự thì gửi đi 1 DupACK với hàm tcp_send_dupack().

 B3: Kiểm tra bit RST, nếu có thì gọi hàm tcp_reset() để thiết lập lại kết nối.  B4: Kiểm bit SYN, nếu có thì gọi hàm tcp_reset()

 B5: Kiểm tra bit ACK, nếu có thì đây là gói tin ACK và gọi hàm tcp_ack().  B6: Kiểm tra bit URG, nếu có thì gọi hàm tcp_urg() để thông báo rằng dữ

liệu đang đến là khẩn cấp.

 B7: Xử lí dữ liệu trong gói tin bằng cách gọi hàm tcp_data_queue()

 B8: Nếu có dữ liệu cần gửi đi thì gọi hàm tcp_data_snd_check(). Hàm này sẽ gọi đến tcp_write_xmit() trong file tcp_output.c. (adsbygoogle = window.adsbygoogle || []).push({});

 B9: Nếu có ACK cần gửi thì gọi hàm tcp_ack_snd_check(). Nếu cần gửi ngay lập tức thì gọi hàm tcp_send_ack() hoặc gửi chậm thì gọi hàm tcp_send_delayed_ack().

Các thông tin liên quan đến ECN đƣợc lƣu trong trƣờng tp→ecn_flags. Khi trƣờng ECN trong phần IP Header của gói tin đến đƣợc thiết lập thì bên nhận sẽ đặt cờ ECE trong phần TCP Header của gói tin ACK gửi đi.

Hình 23 – Các hàm liên quan đến xử lý ECN

Trƣờng ECN đƣợc kiểm tra thông qua hàm TCP_ECN_check_ce() và thủ tục này đƣợc thực hiện từ lời gọi của hàm tcp_event_data_recv() và tcp_data_queue(). Nếu

trƣờng ECN thì bit TCP_ECN_DEMAND_CWR sẽ đƣợc đặt trong trƣờng tp→ecn_flags. Ý nghĩa của bit này là bên nhận sẽ tiếp tục gửi các gói tin ACK với cờ ECE cho đến khi nhận đƣợc bit CWR trong phần TCP Header của gói tin Sender gửi đến.

Khi Sender nhận đƣợc gói tin ACK thì nó sẽ kiểm tra xem cờ ECE trong phần TCP Header có đƣợc đặt hay không thông qua hàm TCP_ECN_rcv_ecn_echo() đƣợc gọi từ tcp_ack(). Nếu có thì sẽ chuyển sang trạng thái TCP_CA_CWR thông qua tcp_enter_cwr() đƣợc gọi từ tcp_try_to_open(). Tại đây, hàm TCP_ECN_queue_cwr() đƣợc gọi để thiết lập bit TCP_ECN_QUEUE_CWR trong trƣờng hợp tp→ecn_flags.

Trong quá trình gửi các gói tin mới thì Sender sẽ xác định xem có cần thiết phải đặt cờ CWR trong phần TCP Header hay không, điều này đƣợc thực hiện bằng cách gọi hàm TCP_ECN_send() từ tcp_transmit_skb() để kiểm tra xem bit TCP_ECN_QUEUE_CWR có đƣợc đặt trong trƣờng tp→ecn_flags. Sau khi gửi tin với bit CWR trong phần TCP Header thì Sender sẽ xóa bit TCP_ECN_QUEUE_CWR trong trƣờng tp→ecn_flags.

4.2 Cài đặt giải thuật cải tiến DCTCP-FA

Các giải thuật TCP đƣợc cài đặt trong phần Networking của nhân Linux. Bởi vì Linux là mã nguồn mở nên cho phép ta có thể chỉnh sửa các giải thuật sao cho nó hoạt động theo ý mình. Trƣớc khi bắt đầu cài đặt giải thuật đề xuất DCTCP-FA, ta tìm hiểu về giải thuật TCP trong mã nguồn nhân Linux, phiên bản 3.2.18.

Phát hiện tắc nghẽn

Giống nhƣ giải thuật DCTCP, về cơ bản giải thuật mới đề xuất này giữ nguyên hầu hết các pha trong mô hình quản lý tắc nghẽn của TCP.

Nếu nhƣ trong TCP, khi bên nhận nhận đƣợc các gói tin bị đánh dấu cờ CE trong phần IP Header thì nó sẽ gửi các gói tin ACK với cờ ECE trong phần TCP Header

cho đến nào khi nhận đƣợc phản hồi là cờ CWR trong phần TCP Header thông báo rằng Sender đã giảm cửa sổ tắc nghẽn.

Cài đặt giải thuật cải tiến DCTCP-FA

Công cụ mô phỏng Mininet