đồ án: Giao thức điều khiển tốc độ tránh nghẽn TFRC

đồ án:án Giao thức điều khiển tốc độ tránh nghẽn TFRC Chương I: Giới thiệu tổng quan về mô hình TCP/IP và vấn đề điều khiển nghẽn trên mạngChương II: Tìm hiểu cơ chế hoạt động của giao thức TFRCChương III: Đưa ra một số ưu nhược điểm của TFRC và một số phương pháp cải tiến giao thức TFRC trong môi trường không dây.Chương IV: Chương trình mô phỏng bằng NS-2.Trong quá trình học tập tại Học viện công nghệ Bưu Chính Viễn Thông và thực hiện đồ án, em xin chân thành cảm ơn các thầy cô đã giúp đỡ em hoàn thành tốt chương trình học tập. Đặc biệt em xin chân thành cảm ơn cô giáo, Ths.Nguyễn Thị Thu Hằng đã tận tình hướng dẫn, tạo điều kiện giúp đỡ em hoàn thành đồ án này

MỤC LỤC

MỤC LỤC i

DANH MỤC HÌNH VẼ VÀ BẢNG BIỂU iv

THUẬT NGỮ VIẾT TẮT vi

LỜI NÓI ĐẦU 1

CHƯƠNG I: TỔNG QUAN VỀ TCP/IP VÀ ĐIỀU KHIỂN NGHẼN 3

1.1 Giới thiệu chung về TCP/IP 3

1.1.1 Mô hình TCP/IP 3

1.1.2 Giao thức TCP 5

1.1.3 Giao thức UDP 13

1.2 Điều khiển luồng và tránh tắc nghẽn trong mạng 14

1.2.1 Điều khiển tránh nghẽn của TCP 15

1.2.2 Giao thức điều khiển tốc độ tránh nghẽn TFRC (TCP-Friendly Rate Control) .17

CHUƠNG II: GIAO THỨC ĐIỀU KHIỂN TỐC ĐỘ TRÁNH NGHẼN TFRC 20

2.1 Cơ chế của giao thức TFRC 20

2.1.1 Biểu thức thông lượng 20

2.1.2 Các loại gói tin 22

2.2 Giao thức tại máy gửi 23

2.2.1 Đo kích thước gói 24

2.2.2 Khởi tạo tại máy gửi 24

2.2.3 Hoạt động của máy phát khi nhận được một gói phản hồi 24

2.2.4 Kết thúc thời gian không phản hồi 25

2.2.5 Chống các dao động 26

2.2.6 Kế hoạch truyền gói 27

2.3 Tính tỉ lệ sự kiện mất gói 27

2.3.1 Phát hiện các gói bị mất hoặc bị đánh dấu 28

2.3.2 Quá trình dịch từ hồ sơ mất gói sang các sự kiện mất gói 28

2.3.3 Khoảng thời gian mất gói trung bình 30

2.3.4 Cơ chế history Discounting 31

2.4 Giao thức tại máy thu dữ liệu 34

2.4.1 Hoạt động tại máy thu khi nhận được một gói dữ liệu 34

2.4.2 Kết thúc thời gian phản hồi 35

2.4.3 Khởi tạo tại máy thu 35

2.5 Các vấn đề khác 36

2.5.1 Những thay đổi phía phát 36

2.5.2 Vấn đề bảo mật 36

CHƯƠNG III: MỘT SỐ ĐÁNH GIÁ VÀ CÁC CẢI TIẾN CỦA TFRC 38

3.1 Một số đánh giá về giao thức TFRC 38

3.1.1 Cải thiện tính ổn định 38

3.1.2 Tăng tốc độ truyền 39

3.1.3 Giảm tốc độ truyền tương ứng với nghẽn kéo dài 40

3.2 Các tham số đánh giá giao thức và kết quả thực nghiệm 40

3.2.1 Các tham số đánh giá giao thức 40

3.2.2 Các kết quả thực nghiệm 41

3.3 Các cải tiến của TFRC đối với môi trường không dây 46

3.3.1 Những thách thức đối với TFRC trong môi trường không dây 46

3.3.2 TFRC-Jr 48

3.3.3 TFRC Veno 52

3.3.4 Một số phương pháp cải tiến khác của TFRC 56

CHƯƠNG IV: CHƯƠNG TRÌNH MÔ PHỎNG 59

4.1 Giới thiệu công cụ mô phỏng NS-2 59

4.2 Giao diện chương trình mô phỏng 61

4.3 Thiết lập topo hệ thống mạng 62

KẾT LUẬN 69TÀI LIỆU THAM KHẢO viii

DANH MỤC HÌNH VẼ VÀ BẢNG BIỂU

Hình 1.1 Mô hình phân lớp TCP/IP 3

Hình 1.2: Mô hình tham chiếu OSI 4

Hình 1.3 Định dạng của TCP datagram 10

Hình 1.4 Định dạng Option 11

Hình 1.5 Tùy chọn Maximum Segment Size 12

Hình 1.6 Tùy chọn Window Scale Factor 12

Hình 1.7 Tùy chọn SACK 13

Hình 1.8 Tùy chọn Timestamp 13

Hình 1.9 Định dạng của UDP datagram 14

Hình 2.1 Cơ chế của giao thức TFRC 20

Hình 2.2 Ví dụ về các sự kiện mất gói 29

Hình 3.1 Cấu hình mạng 41

Hình 3.2 Tốc độ gửi luồng TCP khi có các luồng TFRC 42

Hình 3.3 TCP hoạt động cùng TFRC với hàng đợi RED 43

Hình 3.4 Hệ số biến đổi của thông lượng giữa các luồng 43

Hình 3.5 Các luồng TFRC và TCP phân tích theo kết quả hình 3.2 44

Hình 3.6 40 luồng TCP (a) và TFRC (b) với quản lý hàng đợi Drop-Tail 45

Hình 3.7 Mô hình có dây-không dây đơn giản 46

Hình 3.8 Sự giảm hiệu suất của TCP và TFRC khi có lỗi liên kết vô tuyến trong môi trường ở hình 3.7 47

Hình 3.9 Thông lượng của các luồng TFRC qua các mạng có dây và không dây 47

Hình 3.10 Cấu hình mạng lai có dây-không dây với N luồng 50

Hình 3.11 So sánh TCP và TFRC-Jr trong mạng có dây-không dây với các tỉ lệ lỗi liên kết vô tuyến khác nhau (1 luồng) 50

Hình 3.12 Hiệu suất của nhiều luồng trong môi trường có dây-không dây với tỉ lệ lỗi

là 0,005 51

Hình 3.13 TFRC và tỉ lệ goodput TFRC-Jr với các luồng TCP 52

Hình 3.14 Cấu hình mô phỏng 54

Hình 3.15 So sánh thông lượng của các luồng đơn với Wb = 5Mbps, Delayb=80ms, tỉ lệ lỗi ngẫu nhiên là 0,01 54

Hình 3.16 So sánh thông lượng khi có nhiều luồng với Wb=5Mbps, Delayb=80ms, tỉ lệ lỗi ngẫu nhiên là 0,01 55

Hình 3.17 Tính thân thiện của TFRC Veno với 56

Hình 4.2 Luồng các sự kiện cho file Tcl chạy trong NS 60

Hình 4.3 Giao diện chương trình mô phỏng: (a) cửa sổ lệnh, (b) cửa sổ Nam, (c) cửa sổ xgraph, (d) cửa sổ hiện thị Nam 61

Hình 4.4 Topo mạng thực hiện mô phỏng 62

Bảng 4.1 Tham số của các liên kết trong mạng 62

Bảng 4.2 Các loại gói tin 63

Bảng 4.3 Thời gian các sự kiện xảy ra trong quá trình mô phỏng 63

Hình 4.5 Thời gian các sự kiện xảy ra trong quá trình mô phỏng 64

Hình 4.6 Thông lượng của TCP tại nút 2 khi không có lưu lượng TFRC 64

Hình 4.7 Thông lượng TCP tại nút 2 khi có lưu lượng TFRC 65

Hình 4.8 Thông lượng của TFRC tại nút 2 khi không có lưu lượng TCP 65

Hình 4.9 Thông lượng của TFRC và TCP khi hoạt động cùng nhau 66

Bảng 4.4 Độ fairness giữa TCP và TFRC 67

Hình 4.10 Thông lượng của TFRC và TCP khi thay đổi băng thông cổ chai lên 1Mbps và thời gian mô phỏng là 41s 67

THUẬT NGỮ VIẾT TẮT

AIMD Additive Increase Multiplicative

Decrease

Tăng theo cấp số cộng, giảm theocấp số nhân

ARP Address Resolution Protocol Giao thức phân giải địa chỉ

ARPA Advance Research Projects

Agency

Trung tâm nghiên cứu cấp cao

CoV Coefficient of variation Hệ số biến đổi

CRC Cyclic Redundancy Check Kiểm tra dư chu trình

DCCP Datagram congestion control

Protocol

Giao thức điều khiển nghẽndatagram

ECN Explicit congestion notification Thông báo nghẽn cụ thể

EWMA Exponential Weighted Moving

Average

Trung bình dịch chuyển có trọng sốtăng theo hàm mũ

FIFO Frist in frist out Vào trước ra trước

FTP File transfer protocol Giao thức truyền file

HTTP Hyper Text Transfer Protocol Giao thức truyền siêu văn bản

ICMP Internet Control Message Protocol Giao thức tín hiệu điều khiển

Internet

MSS Maximum Segment Size Kích cỡ đoạn lớn nhất

MTU Maximum Transfer Unit Đơn vị truyền tối đa

OSI Open Systems Interconection Mô hình tham chiếu liên kết hệ

thống mởRARP Reverse Address Resolution

Protocol

Giao thức phân giải địa chỉ ngược

RED Random Early Detection Phát hiện sớm ngẫu nhiên

RTP Realtime Protocol Giao thức thời gian thực

RTT Round-trip Time

SACK Selective acknowledgement Xác nhận có lựa chọn

SCTP Stream Control Transmission

TFRC TCP-Friendly Rate Control Giao thức điều khiển tốc độ thân

thiện TCP

UDP User Datagram Protocol Giao thức dữ liệu người dùng

LỜI NÓI ĐẦU

Với sự phát triển nhanh chóng của các mạng băng thông rộng và các máy tính hiệu suất cao, ngày càng nhiều ứng dụng đa phương tiện thời gian thực xuất hiện trên mạng Internet như điện thoại, hội nghị truyền hình, thoại theo yêu cầu (VoD),…Các ứng dụng thời gian thực này khác với các ứng dụng truyền thống trên Internet như web, FTP, TELNET ở chỗ chúng nhạy với trễ và jitter nhưng có thể chấp nhận một số gói mất Hiện nay băng thông mạng vẫn chưa đáp ứng được yêu cầu của các dịch vụ kiểu này và vấn đề nghẽn mạng xảy ra thường xuyên Điều khiển tốc độ để tránh nghẽn là một trong những vấn đề được quan tâm và nghiên cứu rộng rãi

TCP không thích hợp với các luồng thời gian thực do có sự thay đổi lớn về tốc độ gửi vì vậy giao thức truyền tải phi kết nối UDP được sử dụng để truyền tải các ứng dụng thời gian thực này Nhưng có một vài vấn đề mới nổi lên: UDP là cơ chế best effort không có điều khiển nghẽn, có thể phù hợp với yêu cầu của các luồng thời gian thực nhưng không bình đẳng với các luồng TCP Nói cách khác, khi cùng yêu cầu băng thông với các luồng TCP, các luồng UDP có thể đạt được băng thông lớn hơn một cách không bình đẳng làm giảm hiệu suất của TCP cũng như làm cho vấn đề tắc nghẽn mạng thêm nghiêm trọng thậm chí dẫn đến sập mạng vì nghẽn.

Để giải quyết vấn đề này, ban đầu S.Floyd đề xuất điều khiển nghẽn được thêm vào giao thức truyền tải cho các ứng dụng đa phương tiện thời gian thực để làm cho chúng thân thiện hơn với các luồng TCP Điều đó có nghĩa là khi nghẽn xuất hiện, luồng thời gian thực có thể giành băng thông với các luồng TCP một cách công bằng Phương pháp này được gọi là điều khiển tốc độ thân thiện TCP (TFRC) Trong đồ án này, em sẽ nghiên cứu cơ chế cơ bản, các hoạt động, các đánh giá và các cải tiến của TFRC.

Đồ án Giao thức điều khiển tốc độ tránh nghẽn TFRC bao gồm các nội dung

chính như sau:

Chương I: Giới thiệu tổng quan về mô hình TCP/IP và vấn đề điều khiển nghẽn trên mạng

Chương II: Tìm hiểu cơ chế hoạt động của giao thức TFRC

Chương III: Đưa ra một số ưu nhược điểm của TFRC và một số phương pháp cải tiến giao thức TFRC trong môi trường không dây.

Chương IV: Chương trình mô phỏng bằng NS-2.

Trong quá trình học tập tại Học viện công nghệ Bưu Chính Viễn Thông và thực hiện đồ án, em xin chân thành cảm ơn các thầy cô đã giúp đỡ em hoàn thành tốt

chương trình học tập Đặc biệt em xin chân thành cảm ơn cô giáo, Ths.Nguyễn Thị Thu Hằng đã tận tình hướng dẫn, tạo điều kiện giúp đỡ em hoàn thành đồ án này.

Hà Nội, ngày 10 tháng 11 năm 2008

Sinh viên

Lã Lệ Thủy

CHƯƠNG I: TỔNG QUAN VỀ TCP/IP VÀ ĐIỀU KHIỂN

NGHẼN

Chương này bao gồm các nội dung chính sau: giới thiệu chung về mô hình TCP/IP

và hai giao thức truyền tải TCP và UDP; các cơ chế điều khiển nghẽn trên mạng hiệnnay: điều khiển nghẽn theo cơ chế AIMD – tăng theo cấp số cộng giảm theo cấp sốnhân của TCP và điều khiển nghẽn dựa trên biểu thức – TFRC

1.1 Giới thiệu chung về TCP/IP

1.1.1 Mô hình TCP/IP

TCP/IP là một bộ giao thức được phát triển bởi cục các dự án nghiên cứu cấp cao(ARPA) của bộ quốc phòng Mỹ [6] Ban đầu mô hình này được sử dụng trong mạngARPANET Khi công nghệ mạng cục bộ phát triển, TCP/IP được tích hợp vào môitrường điều hành UNIX và sử dụng chuẩn Ethernet để kết nối các trạm làm việc vớinhau Đến khi xuất hiện các máy PC, TCP/IP lại được chuyển sang môi trường PC,cho phép các máy PC chạy DOS và các trạm làm việc chạy UNIX có thể liên tác trêncùng một mạng Phiên bản hiện hành của TCP/IP được tiêu chuẩn hóa vào tháng 9năm 1981 Hiện nay TCP/IP được sử dụng rất phổ biến trong mạng máy tính mà điểnhình là mạng Internet Bộ giao thức TCP/IP là sự kết hợp của các giao thức khác nhau

ở các lớp khác nhau và không chỉ có giao thức TCP/IP Mô hình TCP/IP được chiathành 4 lớp: lớp ứng dụng, lớp truyền tải, lớp Internet và lớp truy cập mạng như trênhình 1.1

Hình 1.1 Mô hình phân lớp TCP/IP

Tham chiếu qua mô hình OSI, lớp ứng dụng của mô hình TCP/IP tương ứng với

ba lớp trong mô hình OSI là lớp ứng dụng, lớp trình diễn và lớp phiên; lớp giao vậntương ứng với lớp giao vận; lớp liên mạng tương ứng với lớp mạng; lớp truy nhậpmạng tương ứng với lớp liên kết dữ liệu và lớp vật lý

Hình 1.2: Mô hình tham chiếu OSI

• Lớp ứng dụng (Application layer): Lớp này cung cấp và điều khiển các giao

thức ứng dụng người dùng bao gồm các giao thức mức cao, mã hóa, điều khiển hộithoại,.… Các dịch vụ ứng dụng tiêu biểu như FTP (File Transfer Protocol), Telnet(TERminal NETwork), HTTP (Hyper Text Transfer Protocol), …

• Lớp giao vận (Transfer Protocol): Còn gọi là lớp vận chuyển có nhiệm vụ

tryền dẫn dữ liệu từ trạm nguồn tới các trạm đích Lớp này thiết lập kết nối từ haiđiểm đầu cuối của mạng gửi và nhận Nhiều kết nối có thể được thực hiện đồng thời.Tại lớp này có hai giao thức chính là TCP và UDP Phần lớn các dịch vụ ứng dụngngười dùng trong lớp giao vận sử dụng giao thức TCP - là giao thức hướng kết nối tincậy có khả năng điều khiển luồng và chống tắc nghẽn theo cơ chế sử dụng cửa sổtrượt Một số ứng dụng khác sử dụng giao thức UDP - là giao thức phi kết nối, khôngtin cậy và là dịch vụ nỗ lực tối đa (best effort) Thông thường UDP được sử dụng chocác dịch vụ có cơ chế truyền dẫn nhanh và có thể cho phép mất gói Cả TCP và UDPđều thực hiện phân mảnh dữ liệu của các ứng dụng tầng trên, gửi các phân đoạn dữliệu từ thiết bị đầu cuối này tới thiết bị đầu cuối kia

• Lớp Internet (Internet layer): Lớp này cung cấp chức năng đánh địa chỉ để

thực hiện chức năng chọn đường tốt nhất qua mạng cho một gói tin IP là giao thứcquan trọng nhất trong lớp này, nó chỉ cung cấp dịch vụ truyền dẫn dữ liệu nỗ lực tối

đa và phi kết nối IP không cung cấp tính tin cậy, điều khiển luồng cũng như phục hồilỗi, các yếu tố này chỉ được cung cấp bởi các giao thức lớp trên IP cung cấp chức

năng định tuyến để truyền dẫn bản tin đến đích Một đơn vị bản tin trong mạng IPđược gọi là IP datagram Ngoài ra còn có các giao thức lớp mạng khác như ICMP(giao thức tín hiệu điều khiển Internet), ARP (giao thức phân dải địa chỉ) và RARP(giao thức phân dải địa chỉ ngược).

• Lớp truy cập mạng (Network access layer): Cung cấp giao tiếp với lớp vật

lý, kiểm soát lỗi cho dữ liệu phân bố trên mạng vật lý Lớp này có thể có hoặc khôngcung cấp quá trình truyền dẫn tin cậy Tại đây, nó không định nghĩa giao thức TCP/IPcũng như một giao thức nào nhưng nó có thể sử dụng hầu hết các giao diện mạng sẵn

có như IEEE802.2, X.25, ATM, FDDI,… Tuy nhiên đối với TCP/IP thì giao thứcđược sử dụng rộng rãi nhất vẫn là Ethernet trong mạng LAN và mạng WAN Lớp này

có chức năng ánh xạ từ địa chỉ IP sang địa chỉ vật lý và đóng khung dữ liệu IP Dựatrên phần cứng và giao diện mạng tương ứng mà sẽ xác định kết nối với phương tiệnvật lý của mạng

1.1.2 Giao thức TCP

Giao thức TCP (Transmission Control Protocol - "Giao thức điều khiển truyềnvận") là một trong các giao thức cốt lõi của bộ giao thức TCP/IP [8] Sử dụng TCP,các ứng dụng trên các máy chủ được nối mạng có thể tạo các "kết nối" với nhau, màqua đó chúng có thể trao đổi dữ liệu hoặc các gói tin Giao thức này đảm bảo chuyểngiao dữ liệu tới nơi nhận một cách tin cậy và đúng thứ tự TCP phân biệt giữa dữ liệucủa nhiều ứng dụng (chẳng hạn, dịch vụ web và dịch vụ thư điện tử) đồng thời chạytrên cùng một máy chủ TCP hỗ trợ nhiều giao thức ứng dụng phổ biến nhất trên

Internet và các ứng dụng kết quả, trong đó có www, thư điện tử và Secure Shell.Trong bộ giao thức TCP/IP, TCP là tầng trung gian giữa giao thức IP bên dưới và

ống để liên lạc với nhau, trong khi giao thức IP không cung cấp những dòng kiểu đó

mà chỉ cung cấp dịch vụ chuyển gói tin không đáng tin cậy TCP làm nhiệm vụ của

Các ứng dụng gửi các dòng gồm các byte 8-bit tới TCP để chuyển qua mạng TCPphân chia dòng byte này thành các đoạn (segment) có kích thước thích hợp (thườngđược quyết định dựa theo kích thước của đơn vị truyền dẫn tối đa (MTU) của tầng liên

không có gói tin nào bị thất lạc bằng cách gán cho mỗi gói tin một "số thứ tự"(sequence number) Số thứ tự này còn được sử dụng để đảm bảo dữ liệu được trao choứng dụng đích theo đúng thứ tự Modul TCP tại đầu kia gửi lại tin báo nhận(acknowledgement) cho các gói tin đã nhận được thành công Một "đồng hồ" (timer)tại máy gửi sẽ báo time-out nếu không nhận được tin báo nhận trong khoảng thời gian

bằng một round-trip time (RTT), và dữ liệu (được coi là bị thất lạc) sẽ được gửi lại.TCP sử dụng checksum (giá trị kiểm tra) để xem có byte nào bị hỏng trong quá trìnhtruyền hay không Giá trị này được tính toán cho mỗi khối dữ liệu tại bên gửi trướckhi nó được gửi và được kiểm tra tại bên nhận.

Không như giao thức UDP - giao thức có thể lập tức gửi gói tin mà không cần thiếtlập kết nối, TCP đòi hỏi thiết lập kết nối trước khi bắt đầu gửi dữ liệu và kết thúc kếtnối khi việc gửi dữ liệu hoàn tất Cụ thể, các kết nối TCP có ba pha:

ESTABLISHED: cổng đã sẵn sàng nhận/gửi dữ liệu với TCP ở xa (đặt bởi TCPclient và server)

TIME-WAIT: đang đợi qua đủ thời gian để chắc chắn là TCP ở xa đã nhận đượctin báo nhận về yêu cầu kết thúc kết nối của nó Một kết nối có thể ở tại trạng tháiTIME-WAIT trong vòng tối đa 4 phút

Để thiết lập một kết nối, TCP sử dụng một quy trình bắt tay 3 bước (3-wayhandshake) Trước khi client thử kết nối với một server, server phải đăng ký một cổng

và mở cổng đó cho các kết nối - được gọi là mở bị động Một khi mở bị động đã đượcthiết lập thì một client có thể bắt đầu mở chủ động Quy trình bắt tay 3 bước xảy ranhư sau:

1 Mở chủ động được thực hiện bằng cách gửi một SYN cho server

2 Server trả lời bằng một SYN-ACK

3 Cuối cùng, client gửi một ACK lại cho server

Đến đây, cả client và server đều đã nhận được một tin báo nhận (ACK) về kết nối.Lúc này cả hai bên đều có thể bắt đầu truyền và có thể ngắt kết nối bất cứ lúc nàokhông có nhu cầu truyền nữa.

Để kết thúc kết nối hai bên sử dụng quá trình bắt tay 4 bước và chiều của kết nốikết thúc độc lập với nhau Khi một bên muốn kết thúc, nó gửi đi một gói tin FIN vàbên kia gửi lại tin báo nhận ACK Vì vậy, một quá trình kết thúc tiêu biểu sẽ có 2 cặpgói tin trao đổi Một kết nối có thể tồn tại ở dạng "nửa mở": một bên đã kết thúc gửi

dữ liệu nên chỉ nhận thông tin, bên kia vẫn tiếp tục gửi

Một số đặc điểm cơ bản của TCP để phân biệt với UDP:

• Truyền dữ liệu không lỗi (do có cơ chế sửa lỗi/truyền lại)

• Truyền các gói dữ liệu theo đúng thứ tự

• Truyền lại các gói dữ liệu mất trên đường truyền

• Loại bỏ các gói dữ liệu trùng lặp

• Cơ chế tránh tắc nghẽn đường truyền

Ở hai bước đầu tiên trong bắt tay ba bước, hai máy tính trao đổi một số thứ tự góiban đầu (Initial Sequence Number -ISN) Số này có thể chọn một cách ngẫu nhiên Sốthứ tự này được dùng để đánh dấu các khối dữ liệu gửi từ mỗi máy tính Sau mỗi byteđược truyền đi, số này lại được tăng lên Nhờ vậy ta có thể sắp xếp lại chúng khi tớimáy tính kia bất kể các gói tới nơi theo thứ tự thế nào Trên lý thuyết, mỗi byte gửi điđều có một số thứ tự và khi nhận được thì máy tính nhận gửi lại tin báo nhận (ACK).Trong thực tế thì chỉ có byte dữ liệu đầu tiên được gán số thứ tự trong trường số thứ tựcủa gói tin và bên nhận sẽ gửi tin báo nhận bằng cách gửi số thứ tự của byte đang chờ

Ví dụ: Máy tính A gửi 4 byte với số thứ tự ban đầu là 100 (theo lý thuyết thì 4 byte sẽ

có thứ tự là 100, 101, 102, 103) thì bên nhận sẽ gửi tin báo nhận có nội dung là 104 vì

đó là thứ tự của byte tiếp theo nó cần Bằng cách gửi tin báo nhận là 104, bên nhận đãngầm thông báo rằng nó đã nhận được các byte 100, 101, 102 và 103 Trong trườnghợp 2 byte cuối bị lỗi thì bên nhận sẽ gửi tin báo nhận với nội dung là 102 vì 2 byte

100 và 101 đã được nhận thành công

Giả sử ta có 10.000 byte được gửi đi trong 10 gói tin 1.000 byte và có 1 gói tin bịmất trên đường truyền Nếu gói bị mất là gói đầu tiên thì bên gửi sẽ phải gửi lại toàn

bộ 10 gói vì không có cách nào để bên nhận thông báo nó đã nhận được 9 gói kia Vấn

đề này được giải quyết trong giao thức SCTP (Stream Control Transmission Protocol)với việc bổ sung báo nhận chọn lọc

Số thứ tự và tin báo nhận giải quyết được các vấn đề về lặp gói tin, truyền lạinhững gói bị hỏng hoặc mất và các gói tin đến sai thứ tự Để phục vụ mục đích kiểmtra, các gói tin có trường giá trị tổng kiểm tra (checksum) Với trình độ hiện tại, kỹ

thuật tổng kiểm tra trong TCP không đủ mạnh Các tầng liên kết dữ liệu với xác suấtlỗi bit cao có thể cần được bổ sung các khả năng phát hiện lỗi tốt hơn Hiện nay TCPđược thiết kế bao gồm trường kiểm tra dư chu trình (cyclic redundancy check - CRC)với độ dài 32 bit Tuy nhiên điều này cũng không có nghĩa là trường kiểm tra tổng củaTCP là không cần thiết Thống kê cho thấy các sai sót do cả phần cứng và phần mềmgây ra giữa các điểm áp dụng kỹ thuật kiểm tra CRC là khá phổ biến và kỹ thuật kiểmtra tổng có khả năng phát hiện phần lớn các lỗi đơn giản này.

Cuối cùng là khả năng hạn chế tắc nghẽn Tin báo nhận (hoặc không có tin báonhận) là tín hiệu về tình trạng đường truyền giữa 2 máy tính Từ đó, hai bên có thểthay đổi tốc độ truyền nhận dữ liệu phù hợp với điều kiện mạng Vấn đề này thườngđược đề cập như là điều khiển lưu lượng, kiểm soát tắc nghẽn TCP sử dụng một số cơchế nhằm đạt được hiệu suất cao và ngăn ngừa khả năng nghẽn mạng Các cơ chế nàybao gồm: cửa sổ trượt (sliding window), thuật toán slow-start, thuật toán tránh nghẽnmạng (congestion avoidance), thuật toán truyền lại và phục hồi nhanh, Hiện nay,vấn đề cải tiến TCP trong môi truyền truyền dẫn tốc độ cao đang là một hướng nghiêncứu được quan tâm

Kích thước cửa sổ

Chuỗi số thứ tự gói và cửa sổ trong TCP hoạt động giống như một cái đồng hồ.Kích thước của cửa sổ (đo bằng byte) được thiết lập bởi khả năng tiếp nhận của máytính nhận Cửa sổ này được dịch đi mỗi khi máy tính nhận nhận được dữ liệu và gửitin báo nhận Khi chuỗi thứ tự tăng đến tối đa thì quay lại về 0 Kích thước của cửa sổ

là chiều dài (byte) của khối dữ liệu có thể lưu trong bộ đệm của bên nhận Bên gửi chỉ

có thể gửi tối đa lượng thông tin chứa trong cửa sổ này trước khi nhận được tin báonhận

Để tận dụng khả năng truyền dẫn của mạng thì cửa sổ dùng trong TCP cần đượctăng lên Trường điều khiển kích thước cửa sổ của gói TCP có độ dài là 2 byte và do

đó kích thước tối đa của cửa sổ là 65.535 byte Do trường điều khiển không thể thayđổi nên người ta sử dụng một hệ số dãn nào đó Hệ số này được định nghĩa trong tàiliệu RFC 1323 có thể sử dụng để tăng kích thước tối đa của cửa sổ từ 65.535 byte lêntới 1 gigabyte Tăng kích thước cửa sổ lớn hơn nữa cũng cần thiết trong TCP Tuning.Việc tăng kích thước cửa sổ chỉ được dùng trong giao thức bắt tay 3 pha Giá trị củatrường co dãn cửa sổ thể hiện số bit cần được dịch trái đối với trường kích thước cửa

sổ Hệ số dãn có thể thay đổi từ 0 (không dãn) tới 14 (dãn tối đa)

Các cổng TCP

TCP sử dụng khái niệm số hiệu cổng (port number) để định danh các ứng dụng gửi

và nhận dữ liệu Mỗi đầu của một kết nối TCP có một số hiệu cổng (là số không dấu16-bit) được gán cho ứng dụng đang nhận hoặc gửi dữ liệu Các cổng được phânthành ba loại cơ bản: thông dụng, được đăng ký và động/cá nhân Các cổng thôngdụng đã được gán bởi tổ chức Internet Assigned Numbers Authority (IANA) ví dụ:

FTP (21), TELNET (23), SMTP (25) và HTTP (80) Các cổng được đăng ký thườngđược sử dụng bởi các ứng dụng người dùng đầu cuối (end user application) với vai tròcác cổng phát tạm thời (khi dùng xong thì hủy đăng ký) khi kết nối với server, nhưngchúng cũng có thể định danh các dịch vụ có tên đã được đăng ký bởi một bên thứ ba.Các cổng động/cá nhân cũng có thể được sử dụng bởi các ứng dụng người dùng đầucuối, nhưng không thông dụng bằng Các cổng động/cá nhân không có ý nghĩa gì nếukhông đặt trong một kết nối TCP Có 65535 cổng được chính thức thừa nhận

Sự phát triển của TCP

TCP là một giao thức phức tạp và vẫn còn tiếp tục được phát triển Mặc dù cónhiều cải tiến đã được áp dụng và đề xuất nhưng các hoạt động cơ bản của giao thứcvẫn giữ nguyên như mô tả ban đầu trong tài liệu RFC 793 ban hành năm 1981 Tàiliệu RFC 1122 - Các yêu cầu của máy mạng Internet - đưa ra một số yêu cầu khi thựchiện TCP RFC 2581 - Điều khiển tránh nghẽn mạng, một trong những tài liệu quantrọng trong bộ RFC những năm gần đây - mô tả thuật toán dùng để giảm khả năng tắcnghẽn mạng Năm 2001, RFC 3168 mô tả một cơ chế báo hiệu chống nghẽn mạng cótên là: thông báo nghẽn mạng (Explicit Congestion Notification) Vào thời điểm đầu

TCP là HTTP/HTTPS (World Wide Web), SMTP/POP3/IMAP (e-mail) và FTP

(truyền file) Sự phổ biến của TCP chứng tỏ rằng nó đã được thiết kế rất tốt

Cơ chế điều khiển tránh tắc nghẽn của TCP ban đầu là TCP Reno và gần đây đã cómột số thuật toán khác được đề xuất:

Protocol) của Caltech

Bên cạnh đó cũng có rất nhiều nghiên cứu so sánh sự công bằng và hiệu suất củaTCP khi sử dụng các thuật toán tránh tắc nghẽn khác nhau

TCP cũng được sử dụng cho mạng không dây Ở đây trường hợp mất gói tin cũngđược xem là nghẽn mạng và kích thước cửa sổ do đó cũng sẽ được giảm xuống Tuynhiên trong nhiều trường hợp đối với các mạng không dây thì việc mất các gói tinthường xảy ra ngẫu nhiên do ảnh hưởng của fading, chuyển giao giữa các cell vàkhông thể xem đây là nghẽn mạng Do đó, việc giảm kích thước cửa sổ không đúng sẽlàm cho hiệu quả sử dụng đường truyền giảm đáng kể Các giải pháp được đề ra có thểphân loại thành các nhóm: giải pháp đầu cuối (liên quan tới việc thay đổi tạiclient/server), giải pháp tại tầng liên kết dữ liệu (chẳng hạn giao thức RLP trong chuẩn

các thiết bị đầu cuối)

Định dạng gói tin TCP

Một gói tin TCP bao gồm 2 phần: header và dữ liệu Phần header có 11 trườngtrong đó 10 trường bắt buộc Trường thứ 11 là tùy chọn có tên là: option

Hình 1.3 Định dạng của TCP datagram

• Source port: Số hiệu của cổng tại máy tính gửi.

• Destination port: Số hiệu của cổng tại máy tính nhận.

• Sequence number: Trường này có 2 nhiệm vụ Nếu cờ SYN bật thì nó là

số thứ tự gói ban đầu và byte đầu tiên được gửi có số thứ tự này cộng thêm

1 Nếu không có cờ SYN thì đây là số thứ tự của byte đầu tiên

• Acknowledgement number: Nếu cớ ACK bật thì giá trị của trường chính

là số thứ tự gói tin tiếp theo mà bên nhận cần

• Data offset: Trường có độ dài 4 bít qui định độ dài của phần header (tính

theo đơn vị từ 32 bít) Phần header có độ dài tối thiểu là 5 từ (160 bit) và tối

đa là 15 từ (480 bít)

• Reserved: Dành cho tương lai và có giá trị là 0.

• Flags (hay Control bits):Bao gồm 6 cờ

o URG: Cờ cho trường Urgent pointer Giá trị này được thiết lập bởi

máy phát TCP để làm cho bên máy nhận truyền dữ liệu bên trongđoạn đến ứng dụng máy nhận Bất kỳ dữ liệu nào đã nhận trước đâytrên kết nối này nhưng chưa được truyền đến ứng dụng không nhấtthiết phải truyền lần này

o ACK: Cờ cho trường Acknowledgement

o PSH (Hàm Push): Giá trị này được thiết lập bởi bên truyền TCP để

làm cho máy thu ngay lập tức truyền dữ liệu trong đoạn đến Socketcủa bên máy nhận cùng với tất cả các dữ liệu khác mà máy nhậnchưa chuyển đến lớp ứng dụng

o RST: Thiết lập lại đường truyền

o SYN: Đồng bộ lại số thứ tự

o FIN: Không gửi thêm số liệu

• Window: Số byte có thể nhận bắt đầu từ giá trị của trường báo nhận (ACK) Checksum: 16 bít kiểm tra cho cả phần header và dữ liệu 16 bít này là bổ sung

của tổng tất cả các từ 16 bít trong gói tin Trong trường hợp số octet (khối 8bít) của header và dữ liệu là lẻ thì octet cuối được bổ sung với các bít 0 Các bítnày không được truyền Khi tính tổng, giá trị của trường kiểm tra được thay thếbằng 0 Nói một cách khác, tất cả các từ 16 bít được cộng với nhau Kết quả thuđược sau khi đảo giá trị từng bít được điền vào trường kiểm tra

• Urgent pointer: Nếu cờ URG bật thì giá trị trường này chính là số từ 16 bít

mà số thứ tự gói tin (sequence number) cần dịch trái

• Option: Đây là trường tùy chọn Nếu có thì độ dài là bội số của 32 bít.

Đúng như trong trường hợp tuỳ chọn gói dữ liệu IP, tuỳ chọn có thể là:

o Một byte riêng lẻ bao gồm số tuỳ chọn

o Một độ dài tuỳ chọn có thể thay đổi được trong định dạng trong hình1.4

Hình 1.4 Định dạng Option

Một số tùy chọn của TCP.

• Tuỳ chọn Maximum segment size (kích cỡ đoạn lớn nhất): tuỳ chọn này

được sử dụng duy nhất trong suốt quá trình cài đặt kết nối (trường SYN điều khiển bitthiết lập) và gửi từ phía nhận dữ liệu để chỉ ra độ dài đoạn lớn nhất nó có thể điềukhiển được Nó chỉ định nghĩa độ dài tối đa của dữ liệu chứ không phải của toàn bộđoạn Trường này có chiều dài 16 bit nên nó có thể mang giá trị từ 0 đến 65535 Nếutuỳ chọn này không được sử dụng, bất kì kích cỡ đoạn như thế nào cũng được chophép Tùy chọn này chỉ được sử dụng trong quá trình thiết lập kết nối, nó không được

sử dụng trong các phân đoạn trong quá trình truyền dẫn

Hình 1.5 Tùy chọn Maximum Segment Size

• Tuỳ chọn Window Scale Factor - WSF (cỡ cửa sổ): tuỳ chọn này không có

tính bắt buộc Cả hai phía phải gửi tuỳ chọn cỡ cửa sổ trong đoạn SYN để cho phép cỡcửa sổ trong định hướng Cỡ cửa sổ mở rộng theo xác định của cửa sổ TCP tới 32 bit.Định nghĩa kích cỡ cửa sổ 32 bit bằng cách sử dụng kích cỡ cửa sổ 16 bit và hệ số tỉ

lệ Kích thước thật của cửa sổ bằng kích thước cửa sổ chứa trong phần tiêu đề nhânvới 2x, với x là độ lớn (length) trong trường tùy chọn Tuỳ chọn này được quyết địnhtrong giai đoạn thiết lập kết nối Không có cách nào để thay đổi nó sau khi kết nối đãthiết lập

Hình 1.6 Tùy chọn Window Scale Factor

• Tuỳ chọn SACK: Chọn báo nhận (SACK) cho phép máy thu báo tin cho máy

phát về tất cả các đoạn mà máy thu đã nhận thành công Theo đó, máy gửi sẽ chỉ gửilại những đoạn bị mất Nếu số đoạn mà bị mất từ SACK lớn, tuỳ chọn SACK sẽ cũnglớn Do đó, số khối tùy chọn SACK có thể báo cáobị giới hạn tới 4 Để giảm con sốnày, tuỳ chọn SACK nên sử dụng cho nhiều dữ liệu đã nhận trong những khoảng thờigian lân cận

Hình 1.7 Tùy chọn SACK

• Tuỳ chọn Timestamp: Tùy chọn này được máy phát gửi đi Khi máy thu nhận

được gói, nó lưu giá trị của trường này Sau đó nó lại điền giá trị trường này vàotrường timestamp trong phân đoạn xác nhận Khi bên phát nhận được gói xác nhận nólấy thời gian hiện tại trừ đi thời gian chứa trong đoạn xác nhận để biết được thời gian

đi của một gói tin trong mạng

Hình 1.8 Tùy chọn Timestamp

• Các tùy chọn đệm: Đây là loại tùy chọn một byte dùng để căn lề cho dữ liệu

hoặc các tùy chọn khác trong phần tiêu đề

Dữ liệu: Trường cuối cùng không thuộc về header Giá trị của trường này là thông

tin dành cho các tầng trên (trong mô hình 7 lớp OSI) Thông tin về giao thức của tầngtrên không được chỉ rõ trong phần header mà phụ thuộc vào cổng được chọn

xu thế hoạt động nhanh hơn so với TCP Nó thường được dùng cho các ứng dụngkhông đòi hỏi độ tin cậy cao trong giao vận như: giao thức truyền tập tin thường(TFTP), bộ trợ giúp tên miền tên hệ thống, cuộc gọi tiến hành thủ tục từ xa, sử dụng

bởi hệ thống tệp tin mạng (NFS) “gọi thủ tục từ xa (RFC)”, giao thức quản lý mạngđơn giản (SNMP), giao thức truy nhập thư mục đơn giản (LDAP) Khuôn dạng củaUDP datagram được mô tả trong hình 1.9 với các vùng tham số đơn giản hơn nhiều sovới khuôn dạng của TCP datagram.

Hình 1.9 Định dạng của UDP datagramCác trường trong tiêu đề UDP datagram gồm:

• Cổng nguồn: Trường 16 bít này xác định số cổng của chương trình ứng dụng

• Tổng kiểm tra: Trường 16 bít này chứa mã kiểm tra lỗi (theo phương pháp

CRC) cho toàn bộ phân đoạn (cả tiêu đề và dữ liệu)

1.2 Điều khiển luồng và tránh tắc nghẽn trong mạng

Trong quá trình truyền, thông tin thường xảy ra hiện tượng nghẽn tại các nút mạng

do lưu lượng bên ngoài vào vượt quá khả năng xử lý của mạng Khi nghẽn xảy, dữliệu bị trễ được lưu lại trong hàng đợi hay bộ đêm (buffer) của các nút chuyển mạch.Chính hiện tượng này là nguyên nhân gây ra trễ trong quá trình truyền tin và có thểdẫn đến bị mất một số thông tin khi phía phát không xác định được trạng thái của dữliệu đã được gửi đi Nếu lượng thông tin vẫn được đưa hàng đợi vào một cách liên tục

mà mạng không xử lý kịp thì các gói tin không còn chỗ để lưu lại trong hàng đợi và sẽ

bị xóa Khi đó các gói tin bị xóa này phải được phát lại, dẫn đến lãng phí khả năng sửdụng mạng Bên cạnh đó lượng thông tin áp đặt lên mạng quá lớn sẽ làm giảm tốc độ

xử lý của mạng và gây trễ trong quá trình truyền tin Để tránh hiện tượng nghẽn “cổ

chai” như trên, cần có phương pháp để giảm bớt lượng thông tin đưa khi trạng tháithông qua của mạng chưa sẵn sàng.Việc áp dụng một phương pháp nào đó để điềukhiển lưu lượng mạng không có nghĩa là đảm bảo mạng không bị trễ, cho dù đó làdịch vụ mạng thời gian thực (Real- Time) đi chăng nữa Tuy nhiên với một thuật toánđiều khiển luồng và điều khiển tắc nghẽn sẽ đảm bảo một độ trễ cho phép đối với từngdịch vụ Đây chính là chức năng của thuật toán điều khiển luồng và điều khiển tắcnghẽn.

Điều khiển luồng (Flow Control) cho phép điều chỉnh phù hợp số lượng các gói

đang được truyền trên mạng giữa nguồn và đích, nói cách khác là sự phối hợp tốc độtruyền của thiết bị phát với dung lượng bộ đệm của thiết bị thu và của các nút trungchuyển Cơ chế điều khiển luồng được thiết lập với ba mục đích sau:

• Thiết lập sự cân đối giữa việc hạn chế người dùng và giữ tốc độ truyền tintrung bình ở mức hợp lý

• Đảm bảo tính công bằng giữa những người cùng truy cập mạng trongtrường hợp áp dụng điều kiện hạn chế một phần thông tin truy cập

• Duy trì khả năng thông qua của mạng, không để xảy ra hiện tượng nghẽnmạng hoàn toàn

Điều khiển tắc nghẽn (Congestion Control) là tập hợp phân bố các thuật toán để

chia đều tài nguyên mạng sao cho nó phù hợp với sự thay đổi dung lượng và đáp ứngđược như cầu cho nguồn tài nguyên để chặn tắc nghẽn làm sập mạng

Chúng ta cần phân biệt giữa điều khiển luồng và điều khiển tránh tắc nghẽn Điềukhiển luồng là quy định quản lý tốc độ truyền dữ liệu giữa hai đầu kết nối (Node) củamạng, trong khi điều khiển tắc nghẽn là điều khiển luồng dữ liệu khi tắc nghẽn xảy ra

1.2.1 Điều khiển tránh nghẽn của TCP

TCP là một giao thức đầu cuối tới đầu cuối hoạt động trên nền Internet khôngđồng nhất TCP không biết trước được các đặc tính của mạng, do đó nó phải điềuchỉnh trạng thái của nó theo trạng thái hiện tại của mạng TCP được hỗ trợ khả năngđiều khiển tắc nghẽn Điều khiển tắc nghẽn bảo đảm rằng TCP không gửi dữ liệu ởtốc độ lớn hơn tốc độ mà mạng có thể xử lý Tốc độ xấp xỉ của bên gửi là:

đoạn đầu sau khi thiết lập kết nối Nó khởi tạo Wc= 1MSS (maximum segment size)

và sau đó tăng tốc độ truyền một cách nhanh chóng: gấp đôi Wc sau mỗi RTT cho đếnkhi gặp sự kiện mất gói đầu tiên AIMD [7] thực hiện giảm Wc xuống còn một nửasau khi có sự kiện mất gói và tăng Wc lên 1 MSS mỗi RTT khi không có sự kiện mấtgói

Nhìn chung, điều khiển chống nghẽn trong TCP được thực hiện như sau: khởi tạocập nhật ngưỡng tắc nghẽn (CT - congestion threshold) và tùy thuộc vào Wc (cửa sổđiều khiển chống nghẽn) lớn hay nhỏ hơn CT, lưu lượng TCP được điều khiển theohai pha như sau:

+ pha 1: Pha bắt đầu chậm (Wc < CT):

- Wc tăng gấp đôi sau mỗi RTT

- Các gói được truyền vào kênh

+ Pha 2: Pha chống tắc nghẽn (Wc>CT): thực hiện theo thuật toán AIMD

- Wc tăng tuyến tính

- Đường truyền xảy ra tắc nghẽn, giảm Wc xuống còn một nửa

- Cập nhật lại CT (khi có sự kiện timeout, CT được đặt bằng một nửa giá trị của

Wc ngay trước khi xảy ra sự kiện mất gói)

Điều khiển chống nghẽn trong TCP có những nhược điểm cơ bản là:

- Thông tin phản hồi là ẩn và vì vậy cửa sổ gửi luôn giảm đi một nửa khi xảy ratắc nghẽn là không thực sự hiệu quả

- TCP không chia sẻ thông tin điều khiển, vì vậy các kết nối cùng một thời điểmđến cùng một đích (một trường hợp thường xảy ra đối với các lưu lượng web)

sẽ phải cạnh tranh, thay vì phối hợp để sử dụng băng thông mạng một cách hợplý

Do đó điều khiển chống nghẽn của TCP không đáp ứng được đặc biệt trong môitrường nhiều lỗi như môi trường vô tuyến, vệ tinh,…thậm chí thông lượng không thểchấp nhận được Đối với các mạng đa dịch vụ, thuật toán chống tắc nghẽn của TCPkhông đem lại tính bình đẳng cần thiết cho các ứng dụng Đối với các mạng có lưulượng biến đổi động, biến đổi nhanh, điều khiển chống tắc nghẽn của TCP tỏ ra bất ổnđịnh và không hội tụ

Cơ chế điều khiển tắc nghẽn của TCP đã không ngừng được cải tiến và phát triển

mà khởi đầu là TCP Reno Khi những thay đổi đột ngột về tốc độ của TCP trở thành

vấn đề quan trọng đối với sự phát triển của cơ chế điều khiển tắc nghẽn end-to-endcho các ứng dụng luồng đa phương tiện, một giải pháp được đưa ra đó là cơ chế điềukhiển tắc nghẽn dựa trên biểu thức Cơ chế này đảm bảo điều khiển nghẽn thông suốtcho các loại lưu lượng đó với những ưu điểm: độ mịn về tốc độ, đảm bảo tính bìnhđẳng, thân thiện với TCP.

1.2.2 Giao thức điều khiển tốc độ tránh nghẽn TFRC (TCP-Friendly Rate

Control)

TFRC [1,2] là một cơ chế điều khiển tắc nghẽn dựa vào biểu thức Trong khi điềukhiển nghẽn AIDM được thực hiện tương ứng với một dấu hiệu tắc nghẽn, điều khiểntắc nghẽn dựa vào biểu thức là một biểu thức điều khiển mà đưa ra tốc độ gửi tối đachấp nhận được như một hàm của tỉ lệ sự kiện mất gói trong khoảng thời gian lân cận.Thiết bị phát đáp ứng tốc độ gửi của nó, được hướng dẫn bởi biểu thức điều khiểnnày, tương ứng với thông tin phản hồi từ máy thu Đối với lưu lượng mà cùng chạytrong Internet best-effort với TCP, biểu thức điều khiển thích hợp cho điều khiển tắcnghẽn dựa trên biểu thức là một hàm tương ứng với TCP Biểu thức này có đặc điểm

là cung cấp tốc độ gửi bằng tốc độ gửi trạng thái ổn định của TCP như một hàm củaRTT và tỉ lệ sự kiện mất gói trong trạng thái ổn định

Điều khiển tắc nghẽn dựa trên biểu thức không tìm kiếm và sử dụng băng thôngsẵn có một cách “hung hăng” nhưng duy trì một tốc độ gửi tương đối ổn định trongkhi vẫn đáp ứng được tắc nghẽn Để thực hiện được điều này, điều khiển tắc nghẽndựa trên biểu thức thực hiện cân bằng việc hạn chế sử dụng tối đa băng thông có sẵntheo cách thức của TCP Do đó, có một vài nguyên tắc thiết kế cho điều khiển tắcnghẽn dựa trên biểu thức có thể thấy rõ khi so với các hoạt động của TCP

• Không tìm kiếm một cách “hung hăng” ngoài băng thông sẵn có Điều này cónghĩa là tăng tốc độ gửi chậm hơn tương ứng với việc giảm tỉ lệ sự kiện mấtgói

• Không giảm tốc độ gửi xuống 2 lần khi xuất hiện một sự kiện mất gói đơn Tuynhiên, giảm tốc độ gửi đi một nửa khi có vài sự kiện mất gói xuất hiện liên tục.Các ưu điểm thiết kế truyền thống cho điều khiển tắc nghẽn dựa trên biểu thức chocác lưu lượng unicast gồm có:

• Máy thu gửi bản tin phản hồi lại cho máy phát ít nhất một lần mỗi RTT nếu nónhận được các gói trong khoảng thời gian đó

• Nếu máy phát không nhận được phản hồi sau một vài RTT, máy phát sẽ giảmtốc độ gửi của nó và cuối cùng ngừng hoàn toàn việc gửi

TFRC là một cơ chế điều khiển tắc nghẽn đặc trưng cho kiểu điều khiển dựa vàobiểu thức, được thiết kế cho các luồng unicast hoạt động trong môi trường Internet vàhoạt động cùng với các lưu lượng TCP Cơ chế này có thể được sử dụng trong mộtgiao thức truyền tải như RTP, UDP hay DCCP TFRC hoạt động bình đẳng một cáchhợp lý về băng thông với các luồng TCP, ở đó một luồng được gọi là “bình đẳng hợplý” nếu tốc độ gửi của nó là tương đương với tốc độ gửi của một luồng TCP dưới cácđiều kiện như nhau Tuy nhiên, TFRC có sự thay đổi thông lượng theo thời gian thấphơn so với TCP, điều này giúp nó phù hợp hơn với các ứng dụng như điện thoại hoặcluồng đa phương tiện ở đó một tốc độ gửi trơn mịn là điều quan trọng.

Do có thông lượng trơn mịn hơn TCP khi hoạt động bình đẳng về băng thông nênTFRC đáp ứng chậm hơn TCP đối với việc thay đổi băng thông có sẵn Do đó TFRCchỉ nên được sử dụng khi ứng dụng có yêu cầu về thông lượng trơn mịn đặc biệt làtránh việc giảm một nửa tốc độ gửi của TCP khi có một gói bị rớt Đối với các ứngdụng đơn giản chỉ yêu cầu truyền càng nhiều dữ liệu nhất có thể trong một thời gianngắn nhất thì chúng ta đề xuất sử dụng TCP hoặc nếu không yêu cầu độ tin cậy có thể

sử dụng cơ chế điều khiển tắc nghẽn AIMD với các tham số tương tự cho TCP

TFRC được thiết kế cho các ứng dụng sử dụng kích thước gói cố định và thay đổitốc độ gửi của chúng theo gói/s khi có tắc nghẽn TFRC là một cơ chế phía thu với cáctính toán thông tin điều khiển tắc nghẽn ( ví dụ tỉ lệ sự kiện mất gói) trong dữ liệu bênthu hơn là trong dữ liệu bên phát Nó cũng phù hợp hơn với một ứng dụng mà ở đómáy phát là một server lớn điều khiển nhiều kết nối cùng một lúc

Kết luận : TCP/IP là mô hình được sử dụng phổ biến trên mạng máy tính mà điển

hình là mạng Internet Các lưu lượng trên mạng chủ yếu sử dụng hai giao thức truyềntải là TCP và UDP trong đó TCP được sử dụng rộng rãi hơn vì nó có cơ chế điềukhiển tắc nghẽn, truyền lại và khôi phục lỗi nhanh Cùng với sự phát triển khôngngừng của các ứng dụng đa phương tiện thời gian thực, vấn đề tắc nghẽn mạng cũngxảy ra thường xuyên hơn Để giải quyết vấn đề này, giải pháp tăng tài nguyên mạng(tăng các nút mạng, tăng đường truyền, tăng băng thông, ) là khó thực hiện vì chi phílớn và không thể thực hiện thường xuyên Do đó giải pháp phát triển các thuật toán,giao thức điều khiển tắc nghẽn với chi phí nhỏ hơn, không ảnh hưởng đến phần cứngmạng là phương án khả thi, thích hợp với điều kiện mạng hiện nay Hiện nay thuậttoán điều khiển tắc nghẽn của TCP còn tồn tại nhiều điểm không phù hợp với các ứngdụng đa phương tiện thời gian thực Mỗi khi xảy ra tắc nghẽn, TCP giảm tốc độ gửi đimột nửa làm cho tốc độ gửi của TCP không đồng đều đặc biệt trong môi trường tắcnghẽn nghiêm trọng dẫn đến hoạt động không hiệu quả Một thuật toán mới được đưa

ra đó là điều khiển tắc nghẽn dựa trên biểu thức TFRC, ở đó tốc độ gửi là một hàm

của sự kiện mất gói Do đó TFRC đạt được độ trơn mịn về thông lượng thích hợp vớicác ứng dụng đa phương tiện thời gian thực Vậy cơ chế và hoạt động của giao thứcnày như thế nào? Những ưu điểm của nó là gì? Các vấn đề này sẽ được giải quyếttrong các chương tiếp theo.

CHUƠNG II: GIAO THỨC ĐIỀU KHIỂN TỐC ĐỘ TRÁNH

NGHẼN TFRC

Trong chương này sẽ trình bày chi tiết hơn về hoạt động của giao thức điều khiểntốc độ tránh nghẽn TFRC với các nội dung sau: cơ chế của giao thức TFRC, biểu thứcthông lượng (biểu thức điều khiển), các loại gói tin, các hoạt động tại thiết bị phát dữliệu và các hoạt động tại thiết bị thu

2.1 Cơ chế của giao thức TFRC

TFRC là một cơ chế dựa vào máy thu (receiver-based) [2] với các tính toán thôngtin điều khiển xung đột tại máy thu tốt hơn là tại máy phát Đối với cơ chế điều khiểntắc nghẽn của nó, TFRC trực tiếp sử dụng một biểu thức thông lượng cho tốc độ gửicho phép như một hàm của tỉ lệ sự kiện mất gói, round-trip time và kích thước gói.Nói chung, cơ chế điều khiển tắc nghẽn của TFRC (hình 2.1) như sau:

• Máy thu đo tỉ lệ sự kiện mất gói (the loss event rate) và truyền thông tin đócho máy phát

• Máy phát cũng sử dụng các bản tin phản hồi đó để đo round-trip time

• Tỉ lệ sự kiện mất gói và round-trip time sau đó được chuyển vào biểu thứcthông lượng của TFRC để đưa ra tốc độ truyền có thể chấp nhận được

• Máy phát sau đó điều chỉnh tốc độ truyền phù hợp với tốc độ tính toán

Hình 2.1 Cơ chế của giao thức TFRC

2.1.1 Biểu thức thông lượng

Trên các mạng hiện nay, sự tồn tại của các luồng lưu lượng TCP là một tất yếu Vìvậy giao thức TFRC chỉ thực sự được sử dụng rộng rãi khi nó đảm bảo hoạt động thânthiện, bình đẳng với các lưu lượng TCP Một luồng tương thích TCP được định nghĩa

là một luồng mà ở trạng thái ổn định không sử dụng băng thông nhiều hơn so với mộtluồng TCP thông thường chạy trong các điều kiện như nhau Đối với các lưu lượngbest- effort hoạt động cùng TCP trên Internet hiện nay, để trở nên tương thích vớiTCP, lựa chọn đúng đắn cho biểu thức điều khiển là một hàm tương ứng TCP mô tả

tốc độ gửi ở trạng thái ổn định của TCP Nếu chúng ta sử dụng một hàm đáp ứng kémlinh hoạt hơn nhiều khi đó lưu lượng kém linh động hơn có thể bị “chết” khi hoạtđộng cùng lưu lượng TCP trong một hàng đợi FIFO Trong thực tế, khi hai loại lưulượng hoạt động trong một hàng đợi FIFO, hiệu suất có thể chấp nhận được cho hailoại lưu lượng chỉ có kết quả nếu hai loại lưu lượng có các hàm đáp ứng tương tựnhau.

Biểu thức thông lượng chúng ta đề xuất hiện nay cho TFRC là một phiên bản kháđơn giản của biểu thức thông lượng TCP Reno TFRC sử dụng biểu thức thông lượngcủa TCP như một hàm của tỉ lệ sự kiện mất gói và RTT Tuy nhiên, cần chú ý rằngbiểu thức thông lượng TCP đã sử dụng phải phản ánh hoạt động timeout truyền lại,khi điều này ảnh hưởng lớn đến thông lượng TCP tại các tỉ lệ mất gói cao hơn Chúng

ta cũng chú ý rằng các giả thiết ẩn trong biểu thức thông lượng về tham số tỉ lệ sự kiệnmất gói phải là một sự phù hợp hợp lý để thực hiện đo tỉ lệ mất gói hoặc tỉ lệ sự kiệnmất gói Biểu thức thông lượng sử dụng trong TFRC như sau [1,2]:

Ở đó X là tốc độ truyền (byte/s)

S là kích thước gói (byte)

R là round-trip time (s)

p là tỉ lệ sự kiện mất gói (có giá trị từ 0 đến 1)

t_RTO là giá trị timeout cho việc truyền lại TCP (s)

b là số lượng gói được chấp nhận bằng 1 TCP ACK đơn

Máy phát và máy thu cùng sử dụng các số thứ tự cho việc đo RTT Mỗi lần máythu gửi phản hồi nó lặp lại số thứ tự từ gói dữ liệu gần nhất, cùng với thời gian từ lúcgói đó được nhận Trong cách này, máy phát đo RTT qua mạng Máy phát khi đó dànxếp việc đo RTT sử dụng một trung bình dịch chuyển có trọng số tăng theo hàm mũ(EWMA) Trọng số này quyết định tính đáp ứng của tốc độ truyền thay đổi theo RTT.Máy phát cũng nhận được tỉ lệ sự kiện mất gói p trong các bản tin phản hồi từ máy thu

ít nhất một lần/RTT

Máy phát có thể nhận được giá trị timeout truyền lại t_RTO sử dụng thuật toánTCP thông thường:

t_RTO = SRTT +4*RTTvar

Ở đó RTTvar là sự thay đổi của RTT và SRTT là ước tính round-trip time Tuynhiên, trong thực tế t_RTO chỉ ảnh hưởng nghiêm trọng đến tốc độ gửi khi tỉ lệ mấtgói là rất cao Không giống với TCP, TFRC không sử dụng giá trị này để quyết địnhviệc truyền lại có an toàn không và vì vậy hậu quả của việc tính sai là không quánghiêm trọng Trên thực tế, dựa trên những phỏng đoán về kinh nghiệm với t_RTO =4R thì TFRC có thể hoạt động bình đẳng với TCP

Nhiều kết nối TCP hiện nay sử dụng các xác nhận trễ, gửi một ACK cho mỗi haigói dữ liệu nhận được và do đó có một tốc độ gửi được mô hình với b=2 Tuy nhiên,TCP cũng được cho phép để gửi một ACK cho mỗi gói dữ liệu, và nó sẽ được môhình với b=1 Do nhiều hoạt động TCP không sử dụng các xác nhận trễ, RFC 3448 đềxuất b=1 [1]

Các thông số s (kích thước gói), p (tỉ lệ sự kiện mất gói) và R (round-trip time) cầnđược đo hoặc tính toán bởi một hoạt động của TFRC Việc đo s, R, p lần lượt được chỉ

ra ở phần 2.2.1, 2.2.3 và 2.3 Các tốc độ dữ liệu dưới đây được tính theo bytes/s.Trong các phiên bản sau, các biểu thức TCP khác nhau có thể thay thế cho biểuthức này Yêu cầu là biểu thức thông lượng phải là một xấp xỉ hợp lý của tốc độ gửicủa TCP cho điều khiển tắc nghẽn đảm bảo hoạt động của các luồng lưu lượng nàytrên mạng

2.1.2 Các loại gói tin

Trước khi xét đến chức năng máy phát và máy thu, chúng ta mô tả nội dung củacác gói dữ liệu được gửi bởi máy phát và các gói phản hồi được gửi bằng máy thu DoTFRC sẽ được sử dụng với một giao thức truyền tải nên ở đây không chỉ ra các địnhdạng gói vì chúng phụ thuộc vào chi tiết của giao thức truyền tải đã sử dụng

• Các gói dữ liệu

Mỗi gói dữ liệu được gửi bởi máy phát dữ liệu chứa thông tin sau đây:

+ Một số thứ tự (sequence number): Số này được tăng lên một sau mỗi lần một gói dữliệu được truyền Trường này phải đủ lớn sao cho không tồn tại hai gói khác nhau cócùng số thứ tự chứa trong hồ sơ gói gần đây của máy thu tại cùng thời điểm

+ Một thời gian mẫu (timestamp) chỉ ra thời điểm gói được gửi Mỗi gói có số thứ tự

i sẽ có thời gian mẫu là ts_i (thường được đo bằng mili giây) Thời gian mẫu này được

sử dụng bởi máy thu để quyết định những lần mất gói nào thuộc về cùng sự kiện mấtgói Thời gian mẫu cũng được máy thu gửi lại, cho phép máy phát ước lượng RTT đối

với các máy phát mà không lưu các thời gian mẫu của các gói dữ liệu đã phát Ngoài

ra, máy phát cũng có thể lưu các timestamp của các gói dữ liệu đã gửi để ước lượnground-trip time

+ Ước lượng hiện tại về RTT của máy phát Ước lượng đã gửi trong gói i kí hiệu làR_i Ước lượng RTT được sử dụng bởi máy thu cùng với timestamp quyết định khinào nhiều gói mất thuộc về cùng sự kiện mất gói

Các gói phản hồi

Mỗi gói phản hồi được gửi bởi máy thu chứa các thông tin sau:

+ Timestamp của gói dữ liệu nhận được sau cùng Chúng ta kí hiệu là t_recvdata Nếugói nhận được sau cùng tại máy thu có số thứ tự i, khi đó t_recvdata = ts_i.Timestamp này được máy phát sử dụng để ước lượng RTT và chỉ cần thiết khi máyphát không lưu các timestamp của các gói dữ liệu đã phát

+ Khoảng thời gian giữa việc nhận gói dữ liệu sau cùng tại máy thu và việc phát củathông báo phản hồi này kí hiệu là t_delay

+ Tốc độ nhận ước lượng tại máy thu khi thông báo phản hồi sau cùng được gửi kíhiệu là X_recv

+ Ước lượng về tỉ lệ sự kiện mất gói hiện tại của máy thu, p

2.2 Giao thức tại máy gửi

Máy phát gửi một luồng gói dữ liệu đến máy thu theo tốc độ đã điều khiển Mỗilần nhận được một bản tin phản hồi, máy phát tính một giá trị mới cho tốc độ gửi chophép sử dụng hàm tương ứng từ biểu thức thông lượng dựa trên thông tin chứa trongthông báo phản hồi Nếu tốc độ gửi thực Xactual là nhỏ hơn X, máy phát có thể tăng tốc

độ gửi của nó Nếu Xactual lớn hơn X, máy phát giảm tốc độ gửi của nó xuống X Nếumáy phát không nhận một thông báo phản hồi trong hai RTT, nó giảm tốc độ gửi của

nó đi một nửa Điều này đạt được nhờ một bộ định thời gọi là bộ định thời không phảnhồi

Giao thức tại máy gửi thực hiện theo các bước sau đây:

• Đo kích thước gói trung bình đã gửi

• Các hoạt động của máy gửi khi nhận được một gói phản hồi

• Các hoạt động của máy gửi khi bộ định thời không phản hồi kết thúc

• Chống dao động (tùy chọn)

• Sắp xếp việc truyền dẫn trên các hệ thống hoạt động không theo thời gian thực

2.2.1 Đo kích thước gói

Tham số s (kích thước gói) thông thường được biết đến đối với một ứng dụng Cóthể có hai trường hợp:

+ Kích thước gói thay đổi một cách tự nhiên tùy thuộc vào dữ liệu Trongtrường hợp này, mặc dù kích thước gói thay đổi nhưng sự thay đổi đó khôngđược xét đến để thay đổi tốc độ truyền Vì vậy hoàn toàn có thể sử dụng mộtước lượng kích thước gói trung bình, s

+ Ứng dụng cần phải thay đổi kích thước gói hơn là thay đổi số lượng các góitrên mỗi giây để thực hiện điều khiển tắc nghẽn Trường hợp này thông thường

là các gói ứng dụng audio, ở đó mỗi gói cần thiết được đặc trưng bởi mộtkhoảng thời gian cố định Đối với các ứng dụng như vậy cần phải có một cáchkhác hoàn thiện hơn để đo tham số này

Chúng ta không xét đến trường hợp thứ hai Ở đây chúng ta giả thiết rằng máyphát có thể ước lượng kích thước gói, và điều khiển tắc nghẽn đó được thực hiện bởiviệc cân đối số lượng các gói được gửi mỗi giây

2.2.2 Khởi tạo tại máy gửi

Để khởi tạo tại máy gửi, giá trị của X được thiết lập là 1 gói/s và thời gian khôngphản hồi được thiết lập để kết thúc sau 2 giây Giá trị khởi đầu cho R (round-trip time)

và t_RTO chưa có cho đến khi chúng được thiết lập như mô tả dưới đây Giá trị khởiđầu của tld (time last doubled) - thời gian gấp đôi cuối cùng trong pha bắt đầu chậm,được thiết lập là -1 [1]

2.2.3 Hoạt động của máy phát khi nhận được một gói phản hồi

Thiết bị phát biết tốc độ gửi hiện tại của nó, X, và duy trì một ước lượng của RTThiện tại, và một ước lượng của khoảng timeout, t-RTO

Khi máy phát nhận được một gói phản hồi tại thời điểm t_now, nó sẽ thực hiện cácbước sau:

1) Tính một mẫu round trip mới (round trip sample)

R_sample = (t_now – t_recvdata) – t_delay

TFRC không nhạy cảm với giá trị chính xác của hằng số bộ lọc q, nhưng chúng ta

Tính X_calc sử dụng biểu thức thông lượng TCP

X = max (min (X_calc, 2*X_recv), s/t_mbi);

5) Thiết lập lại bộ định thời không phản hồi để kết thúc sau max (4*R, 2*s/X)giây

2.2.4 Kết thúc thời gian không phản hồi

Nếu thời gian không phản hồi kết thúc, máy phát phải thực hiện những hoạt độngsau:

1) Giảm tốc độ gửi di một nửa Nếu máy phát nhận phản hồi từ máy thu, điều nàyđược thực hiện bằng cách thay đổi việc sao chép ngầm X_recv (tốc độ nhận)của máy phát Hầu hết tốc độ gửi bị giới hạn tại hai lần X_recv, việc thay đổiX_recv hạn chế tốc độ gửi hiện tại, nhưng cho phép máy phát thực hiện Slow-start, gấp đôi tốc độ gửi mỗi RTT của nó, nếu các bản tin phản hồi tiếp tụcthông báo không có mất gói

Nếu bộ định thời không phản hồi kết thúc khi máy phát chưa có mẫu RTT, và chưanhận được bất kì phản hồi nào từ máy thu, khi đó bước 1 có thể được bỏ qua và tốc độgửi giảm đi một nửa.

X = max (X/2, s/t_mbi)

3) Restart bộ định thời không phản hồi để kết thúc sau max(4*R, 2*s/X) giây.Khi máy phát ngừng gửi dữ liệu, máy thu sẽ ngừng gửi phản hồi Điều này sẽ dẫnđến việc kết thúc bộ định thời không phản hồi và giảm X_recv Nếu máy phát bắt đầugửi lại, X_recv sẽ giới hạn tốc độ truyền và một pha bắt đầu chậm thông thường sẽxuất hiện cho đến khi tốc độ truyền đạt đến X_calc

Nếu máy phát là rỗi khi thời gian không phản hồi này được thiết lập và X_recv lànhỏ hơn 4 gói/RTT, khi đó X_recv nên giảm đi một nửa nếu bộ định thời kết thúc.Điều này đảm bảo tốc độ gửi cho phép không bao giờ bị giảm nhỏ hơn hai gói/RTTtrong giai đoạn rỗi

2.2.5 Chống các dao động

Để chống dao động trong các môi trường ghép kênh thống kê mức thấp, cần thiếtphải thay đổi tốc độ truyền của máy phát để tránh tắc nghẽn bằng việc giảm tốc độtruyền khi trễ hàng đợi (và do RTT) tăng Để làm được việc này, máy phát duy trì mộtước lượng của RTT dài hạn và thay đổi tốc độ gửi của nó phụ thuộc vào việc mẫu gầnnhất của RTT khác giá trị này như thế nào Mẫu dài hạn là R_sqmean, và nó đượcthiết lập như sau:

Nếu không có phản hồi nào được nhận trước đó

R_sqmean = sqrt (R_sample);

Else R_sqmean = q2*R_sqmean + (1-q2)*sqrt (R_sample);

Do đó R_sqmean đưa ra giá trị trung bình động theo trọng số hàm mũ của căn bậchai của các mẫu RTT Hằng số q2 được thiết lập tương tự như q, RFC 3448 đề xuấtmột giá trị mặc định là 0,9

Máy phát tính tốc độ truyền cơ bản X từ hàm thông lượng Khi đó nó tính một tốc

độ truyền tức thời đã thay đổi X_inst như sau:

X_inst = X * R_sqmean / sqrt (R_sample);

Nếu sqrt (R_sample) lớn hơn R_sqmean khi đó hàng đợi đang tăng và do đó tốc độtruyền cần phải giảm đối với hoạt động ổn định.

Sự thay đổi này không phải luôn luôn là cần thiết, đặc biệt nếu mức độ ghép kênhthống kê trong mạng là cao Tuy nhiên, nếu thực hiện sự thay đổi này sẽ làm choTFRC hoạt động tốt hơn trong các môi trường ghép kênh thống kê mức thấp Nếukhông thực hiện chống dao động, RFC 3448 đề xuất sử dụng một giá trị q nhỏ chẳnghạn như cho q xấp xỉ hoặc bằng 0

2.2.6 Kế hoạch truyền gói

Khi TFRC thực hiện truyền với tốc độ cơ bản và khi các hệ thống hoạt động thôngthường không thể lập lịch các sự kiện một cách chính xác, cần phải biết về việc gửicác gói dữ liệu sao cho duy trì tốc độ gửi trung bình chính xác dù lập lịch của hệ thốnghoạt động theo quy tắc hay bất quy tắc Do đó, một vòng gửi thông thường sẽ tínhkhoảng cách giữa các gói chính xác, t_ipi như sau:

t_ ipi = s/X_inst;

Khi một máy phát bắt đầu gửi lần đầu tại thời điểm t_0, nó tính t_ipi và tính mộtthời gian gửi định danh t_1 = t_0 + t_ipi cho gói 1 Khi ứng dụng trở nên rỗi, nó kiểmtra thời gian hiện tại t_now và khi đó các yêu cầu sắp xếp lại sau (t_ipi – (t_now –t_0)) giây Khi ứng dụng được lập lịch lại, nó kiểm tra thời gian hiện tại t_now mộtlần nữa Nếu (t_now > t_1 – delta) khi đó gói 1 được gửi

Một t_ipi mới có thể được tính và được sử dụng để tính một thời gian gửi địnhdanh t_2 cho gói 2: t2 = t_1 + t_ipi Khi đó quá trình lặp lại, với mỗi lần thời gian gửicủa một gói thành công được tính từ thời gian gửi định danh của gói trước đó

Trong một số trường hợp, khi thời gian gửi định danh t_i của gói kế tiếp được tính,

nó có thể là trường hợp mà t_now > t_i – delta Trong một trường hợp như vậy, gói sẽđược gửi ngay lập tức Tham số delta cho phép sự linh hoạt trong thời gian gửi củamột gói Nếu hệ thống đang vận hành có thời gian lập lịch granularity của t_gran giây,khi đó delta thường được thiết lập thành:

delta = min (t_ipi/2, t_gran/2);

Ở đó t_gran thường được cho là 10ms trên nhiều hệ thống Unix

2.3 Tính tỉ lệ sự kiện mất gói

Đạt được một phép đo tỉ lệ sự kiện mất gói ổn định và chính xác là vấn đề quantrọng cơ bản đối với TFRC Phương pháp tính tỉ lệ sự kiện mất gói là chủ đề của nhiềutranh luận và thử nghiệm với các yêu cầu:

• Tỉ lệ mất gói ước tính nên đo tỉ lệ sự kiện mất gói hơn là tỉ lệ mất gói, ở đó một

sự kiện mất gói có thể bao gồm một vài gói bị mất trong một round-trip time

• Tỉ lệ sự kiện mất gói được ước tính phải bám vết khá đều đặn trong môi trườngvới tỉ lệ sự kiện mất gói trạng thái ổn định bền vững

• Tỉ lệ sự kiện mất gói phải đáp ứng một cách chặt chẽ với các sự kiện mất góitrong một vài round-trip time thành công

• Tỉ lệ sự kiện mất gói ước tính chỉ tăng khi xuất hiện một sự kiện mất gói mới

• Một khoảng thời gian mất gói được định nghĩa như số lượng gói giữa các sựkiện mất gói Tỉ lệ sự kiện mất gói ước tính chỉ tăng khi đáp ứng với mộtkhoảng thời gian mất gói mới mà dài hơn trung bình đã tính trước đó, hoặc mộtkhoảng thời gian đủ dài tính từ sự kiện mất gói cuối cùng

Việc đo tỉ lệ sự kiện mất gói được thực hiện tại máy thu, dựa trên phát hiện mấtgói hoặc các gói đã đánh dấu từ các số thứ tự của các gói đến

2.3.1 Phát hiện các gói bị mất hoặc bị đánh dấu

TFRC giả thiết rằng tất cả các gói chứa một số thứ tự mà tăng lên 1 khi mỗi góiđược gửi Nếu một gói bị mất được truyền lại thì việc truyền lại được đưa cho một sốthứ tự mới là sau cùng trong số truyền dẫn và không phải cùng số thứ tự như gói đãmất Nếu một giao thức truyền tải có yêu cầu là nó phải phát lại với số thứ tự gốc khi

đó người thiết kế giao thức truyền tải phải tính xem phân biệt trễ từ các gói đượctruyền lại như thế nào và cách phát hiện các truyền lại bị mất

Máy thu duy trì một cấu trúc dữ liệu mà bám vết của các gói đã đến và đang thấtlạc Cấu trúc dữ liệu này bao gồm một danh sách các gói đã đến cùng với mẫu thờigian tại máy thu khi mỗi gói được nhận Việc mất gói được phát hiện khi nhận được ítnhất 3 gói với số thứ tự cao hơn gói bị mất Yêu cầu đối với 3 gói liên tiếp là tương tựnhư đối với TCP và làm cho TFRC mạnh hơn khi có sự sắp xếp lại gói Đối lập vớiTCP, trong TFRC nếu một gói đến chậm (sau khi 3 gói liên tiếp đã đến), gói đếnmuộn có thể được điền vào chỗ trống trong hồ sơ nhận của TFRC và máy thu có thểtính lại tỉ lệ sự kiện mất gói Các phiên bản sau của TFRC có thể cần yêu cầu đối với 3gói liên tiếp tương ứng dựa trên việc sắp xếp lại gói đã kiểm nghiệm

2.3.2 Quá trình dịch từ hồ sơ mất gói sang các sự kiện mất gói

TFRC yêu cầu rằng đoạn mất gói là lớn đối với một vài gói bị mất liên tiếp ở đócác gói này là một phần của cùng một sự kiện mất gói Điều này tương tự với TCP màthông thường chỉ thực hiện một nửa cửa sổ tắc nghẽn trong một RTT bất kì Do đó,máy phát cần sắp xếp các gói đã mất vào trong một hồ sơ sự kiện mất gói ở đó một sựkiện mất gói là một hoặc nhiều gói bị mất trong một RTT Để thực hiện việc sắp xếp

này, máy thu cần biết RTT được máy phát gửi định kì như là thông tin điều khiểnđược mang trên một gói dữ liệu.

Hình 2.2 Ví dụ về các sự kiện mất gói

Để quyết định một gói bị mất hoặc bị đánh dấu thuộc một sự kiện mất gói mới hayđược tính như phần của một sự kiện mất gói tồn tại trước đó, cần phải so sánh các sốthứ tự và các thời gian mẫu của các gói tại máy thu Đối với một gói đã đánh dấuS_new, thời gian nhận T_new của nó có thể được quan tâm hơn Đối với một gói bịmất, có thể thực hiện nội suy để tìm “thời gian đến” định danh Giả sử:

S_loss là số thứ tự (sequence number) của gói bị mất

S_before là số thứ tự của gói đến ngay trước gói có số thứ tự S_loss

S_after là số thứ tự của gói đến ngay sau gói có số thứ tự S_loss

T_before là thời gian nhận của S_before

T_after là thời gian nhận của S_after

T_before có thể là trước hoặc sau T_after phụ thuộc vào việc sắp xếp lại

Đối với một gói bị mất S_loss, có thể thực hiện nội suy “thời gian đến” định danhcủa nó tại máy thu từ các thời gian đến của S_before và S_after Do đó:

T_loss = T_before + ( (T_after - T_before)

* (S_loss - S_before)/(S_after - S_before) );

Nếu đoạn số thứ tự bao giữa S_before và S_after khi đó các số thứ tự phải đượcthay đổi để đưa vào tính trước khi thực hiện cách tính này Nếu số thứ tự lớn nhất cóthể là S_max và S_before > S_after, khi đó có thể chỉ cần thay đổi mỗi số thứ tự S bởiS’ = (S + (S_max +1)/2) mod (S_max + 1)

Nếu gói bị mất S_old được quyết định là bắt đầu sự kiện mất gói trước đó vàS_new được cho là đã mất trong khi nội suy các “arrival time” định danh của S_old vàS_new được gọi là T_old và T_new tương ứng.

Nếu T_old + R >= T_new, khi đó S_new là phần của sự kiện mất gói tồn tại Nếukhông S_new là gói đầu tiên trong một sự kiện mất gói mới

2.3.3 Khoảng thời gian mất gói trung bình

Nếu một khoảng thời gian mất gói, A, được quyết định bắt đầu với gói có số thứ tựgói S_A và khoảng thời gian mất gói kế tiếp, B, bắt đầu với gói có số thứ tự gói S_B,khi đó số lượng gói trong khoảng thời gian mất gói A được cho là (S_B – S_A)

Để tính tỉ lệ sự kiện mất gói p, trước tiên phải tính khoảng thời gian mất gói trungbình Điều này được thực hiện bằng cách sử dụng một bộ lọc mà xử lý n khoảng thờigian sự kiện mất gói gần nhất theo một cách mà việc đo tỉ lệ sự kiện mất gói thay đổimột cách mềm dẻo

Trọng số w_0 đến w_(n-1) được tính như sau:

Do đó nếu các khoảng thời gian mất gói gần nhất là I_0 đến I_n, với I_0 trở thànhkhoảng thời gian từ lúc sự kiện mất gói gần nhất, khi đó khoảng thời gian mất góitrung bình I_mean được tính như sau:

I_tot0 = 0;

I_tot1 = 0;

W_tot = 0;

for (i = 0 to n-1) {

I_tot0 = I_tot0 + (I_i * w_i);

W_tot = W_tot + w_i;

Khi có mất gói ngẫu nhiên, tỉ lệ sự kiện mất gói và tỉ lệ mất gói là khá khác nhau

Sự khác nhau giữa tốc độ truyền thay đổi theo hai tỉ lệ này ở trạng thái ổn định thường

là 10% [1,2]

Tại các router sử dụng quản lý hàng đợi RED, nhiều gói bị rớt trong một cửa sổcủa dữ liệu là không phổ biến nhưng với quản lý hàng đợi Drop-tail thì điều này làphổ biến ở đó nhiều gói bị mất khi tràn hàng đợi Kết quả là có một sự khác biệt khálớn giữa hệ số mất gói và hệ số sự kiện mất gói của một luồng và sự khác biệt này yêucầu chúng ta sử dụng hệ số sự kiện mất gói sẽ tốt hơn so trong các hoạt động của môhình TCP dưới các điều kiện này

Khi nghẽn xảy ra nghiêm trọng cũng có thể dẫn đến nhiều gói bị rớt trong một cửa

sổ dữ liệu đối với một số round-trip time, và cũng dẫn đến sự khác biệt lớn giữa hệ sốmất gói và hệ số sự kiện mất gói trong thời gian quá độ đó Trong các trường hợp nhưvậy, TFRC sẽ phản ứng chậm hơn sử dụng hệ số sự kiện mất gói vì hệ số sự kiện mấtgói là nhỏ hơn đáng kể so với hệ số mất gói Tuy nhiên sự khác biệt giữa tỉ lệ mất gói

và tỉ lệ sự kiện mất gói là không rõ ràng nếu tắc nghẽn kéo dài, do tốc độ của TFRCgiảm nhanh theo mỗi gói/RTT

2.3.4 Cơ chế history Discounting

Do phương pháp khoảng thời gian mất gói trung bình lấy trung bình qua một sốkhoảng thời gian mất gói hơn là lấy qua một vài gói đến Phương pháp này với cáctrọng số cố định đáp ứng nhanh và hợp lý khi nghẽn tăng đột ngột, nhưng nó chậm khiđáp ứng với việc giảm đột ngột tỉ lệ mất gói được đặc trưng bởi một khoảng thời gianlớn tính từ sự kiện mất gói cuối cùng Để cho phép một đáp ứng theo thời gian hơnvới một nghẽn giảm liên tục, chúng ta phát triển cơ chế history discounting vớiphương pháp khoảng thời gian mất gói trung bình, cho phép máy thu TFRC thay đổicác trọng số trong phương pháp trung bình có trọng số với các trường hợp đặc biệt của