28 k19t1 improving rtt estimate&&

24
MẠNG VÀ TRUYỀN SỐ LIỆU NÂNG CAO GV: PGS. TS NGUYỄN ĐÌNH VIỆT Topic 28: Improving Round-Trip Time Estimates in ReliableTransport Protocols Nhóm thực hiện: Nguyễn Thị Hồng Hiên Đỗ Thị Loan Ngọc Anh Hà Nội - 2013 1

Upload: tuanhaibk

Post on 03-Jan-2016

14 views

Category:

Documents


1 download

TRANSCRIPT

Page 1: 28 K19T1 Improving RTT Estimate&&

MẠNG VÀ TRUYỀN SỐ LIỆU NÂNG CAO

GV: PGS. TS NGUYỄN ĐÌNH VIỆT

Topic 28:

Improving Round-Trip Time Estimates

in

ReliableTransport Protocols

Nhóm thực hiện: Nguyễn Thị Hồng Hiên Đỗ Thị Loan Ngọc Anh

Hà Nội - 2013 1

Page 2: 28 K19T1 Improving RTT Estimate&&

Topic 28: Improving-RTT-Estimates, GV: PGS. TS. Nguyễn Đình Việt

Đặt vấn đề

• Giao thức TCP có cơ chế truyền lại và biên nhận để truyền phát gói tin một cách đáng tin cậy.

• Tuy nhiên, TCP bị một vấn đề mà ta gọi là retransmission ambiguity:

• Bài báo này tổng quan lại phương pháp truyền lại và trình bày một cách tiếp cận mới, hiệu quả vấn đề truyền lại không rõ ràng.

2/24

Page 3: 28 K19T1 Improving RTT Estimate&&

Topic 28: Improving-RTT-Estimates, GV: PGS. TS. Nguyễn Đình Việt

1.Giới thiệu

Round Trip Time (RTT):

là khoảng thời gian từ lúc gửi một gói tin đến khi nhận được biên nhận. Nó gồm cả

thời gian trễ lan truyền, thời gian ở hàng đợi gateway, thời gian xử lý gói tin và xác

nhận ở bên gửi và bên nhận.

• Trong các mạng diện rộng, sự trễ lan truyền chiếm một phần lớn trong RTT.

• Đánh giá RTT là một chức năng chính trong nhiều giao thức vận chuyển. Nó được sử

dụng để đảm bảo dữ liệu được phân phát một cách đáng tin cậy. Nếu quá lâu mà dữ

liệu vẫn không được biên nhận thì nó được coi là đã bị mất và được truyền lại. Như

vậy đánh giá RTT được dùng để xác định việc truyền lại có xảy ra hay không.

3/24

Page 4: 28 K19T1 Improving RTT Estimate&&

Topic 28: Improving-RTT-Estimates, GV: PGS. TS. Nguyễn Đình Việt

... 1. Giới thiệu

Ba phát triển trong hệ thống mạng IP làm quan tâm hơn đến đánh giá RTT

• Thứ nhất, có sự tăng trưởng bùng nổ về kích thước và độ phức tạp của liên mạng IP

được xây dựng bởi sự kết nối của các mạng con. Internet kết nối một loạt các mạng

lưới với tốc độ, trễ lan truyền, khoảng thời gian dịch vụ khác nhau. Kết quả là RTT

trên Internet biến đổi. Một số mạng cũng có tỉ lệ lỗi tương đối cao và phải loại bỏ một

số gói tin bị hỏng trên đường truyền.

• Thứ hai, có một sự gia tăng lớn truy cập vào một số mạng IP. Lưu lượng truyền tải cao

đã dẫn đến tắc nghẽn mạng nghiệm trọng ở một số bộ phận Internet. Tắc nghẽn cũng

khiến RTT thay đổi nhiều. Nó cũng là nguyên nhân làm mất dữ liệu, ví dụ như

gateway sẽ loại bỏ dữ liệu nếu hàng đợi quá tải.

• Thứ ba, người ta đã CMR phương pháp đánh giá RTT của TCP là không chính xác

nếu gói tin bị mất hoặc RTT biến đổi nhiều.

4/24

Page 5: 28 K19T1 Improving RTT Estimate&&

Topic 28: Improving-RTT-Estimates, GV: PGS. TS. Nguyễn Đình Việt

2. Thuật toán TCP

• Với đặc điểm của TCP, người ta đánh giá RTT bằng cách lấy mẫu các gói tin gửi qua một kết nối và lấy trung bình của các mẫu này thành ước tính RTT đã làm mịn, SRTT.

• Khi một gói tin được gửi, những lần mà bên gửi nhận được biên nhận, sinh ra một chuỗi thời gian S, là những mẫu của thời gian phản hồi: s1, s2, s3…. Với mỗi si giá trị SRTT mới được tính bằng công thức:

SRTTi+1 = (α x SRTTi) + (1-α)x si

trong đó SRTTi là đánh giá RTT đã được làm mịn hiện tại, SRTTi+1 là giá trị mới được tính và α là một hằng số giữa 0 và 1 điều khiển SRTT thích nghi với sự thay đổi nhanh chóng.

• Time-out truyền lại (RTOi) được tính từ SRTTi. Công thức:

RTOi = β x SRTTi

β là một hằng số, lớn hơn 1.

5/24

Page 6: 28 K19T1 Improving RTT Estimate&&

Topic 28: Improving-RTT-Estimates, GV: PGS. TS. Nguyễn Đình Việt

2.1 Nhận xét về thuật toán

• Gọi R(i) là RTT thực của gói tin i. Tương ứng với dãy RTT mà ta đo được si , ta có dãy các giá trị

của R:

s1 = R(1), s2 = R(2),…, si-1 = R(i-1)

• Khi đó RTO(i) có một ràng buộc với R(i), RTT của gói dữ liệu tiếp theo.

• Giá trị của các hằng số α và β cũng ảnh hưởng lớn đến thuật toán

- Giá trị của α có thể làm biến đổi nhanh giá trị của SRTT.

- Chọn giá trị β khó hơn bởi vì nó ảnh hưởng nhiều đến sự mâu thuẫn giữa lượng người dùng và hiệu quả tổng thể mạng lưới.

6/24

Page 7: 28 K19T1 Improving RTT Estimate&&

Topic 28: Improving-RTT-Estimates, GV: PGS. TS. Nguyễn Đình Việt

... 2.1 Nhận xét về thuật toán

• Để đạt được thông lượng người dùng tối ưu β chỉ nên lớn hơn 1 một chút. Điều này

giữ cho RTO rất gần với SRTT và đảm bảo gói tin bị mất nhanh chóng được phát

hiện. Việc phát hiện nhanh gói tin bị mất giúp cho thông lượng trên mạng tốt, bởi vì

cơ chế kiểm soát luồng trong giao thức tin cậy TCP làm cho bên gửi dừng truyền gói

dữ liệu mới nếu một gói dữ liệu vẫn không được biên nhận khi đã quá RTT.

• Đáng tiếc, những gì tốt cho thông lượng người dùng thì lại không tốt cho hiệu quả

mạng lưới. Nếu RTO gần bằng SRTT thì một số lượng lớn gói dữ liệu sẽ được truyền

lại không cần thiết bởi vì time out bên gửi quá nhanh.Ví dụ, trường hợp RTO = SRTT

(β=1) khoảng một nửa tất cả gói dữ liệu sẽ bị time out và được truyền lại.

• Để giảm việc truyền lại, với các đặc điểm của TCP thì β=2 là hợp lý.

7/24

Page 8: 28 K19T1 Improving RTT Estimate&&

Topic 28: Improving-RTT-Estimates, GV: PGS. TS. Nguyễn Đình Việt

2.2. Back-off

• Khi một time out xảy ra, TCP tăng giá trị RTO bằng một số yếu tố trước khi phát lại dữ liệu không được xác nhận. Giá trị RTO sẽ tiếp tục được tăng nếu vẫn truyền lại. Thao tác này được gọi là back-off.

• Mỗi lần truyền lại đơn giản chỉ là tăng gấp đôi RTO. Với bất cứ thuật toán nào, back-off là cần thiết để giữ cho mạng không bị quá tải.

8/24

Page 9: 28 K19T1 Improving RTT Estimate&&

3. SAMPLING ROUND-TRIP TIMES (LẤY MẪU RTT (RTT-thời gian trễ trọn vòng))

• Một giả định quan trọng của thuật toán TCP như sau: một chuỗi mẫu RT là một

phép đo chính xác của một RTT trong mạng thực

Ví dụ: s1=R(1), s2=R(2)...

• Tuy nhiên, phải nhắc đến là hai phương pháp lấy mẫu điển hình, tính toán trên lần

truyền tải đầu tiên và tính toán trên lần truyền tải gần nhất đều cho kết quả không

chính xác.

Topic 28: Improving-RTT-Estimates, GV: PGS. TS. Nguyễn Đình Việt9/24

Page 10: 28 K19T1 Improving RTT Estimate&&

• Sự kém chính xác này có nguyên nhân từ sự truyền lại của gói dữ liệu.

• Thông tin mang trong các gói dữ liệu header của TCP và hầu hết các phương thức

đáng tin cậy khác không được biểu thị nếu như có một sự báo nhận được phản hồi

cho truyền tải gốc của gói dữ liệu hoặc một cho một sự truyền tải lại.

• Kết quả là, một phép đo RTT (thời gian trễ trọn vòng) cho một gói dữ liệu truyền lại

không xác định/nhập nhằng/ không đơn trị.

• Chúng ta gọi vấn đề này là retransmission ambiguity (sự nhập nhằng/ không rõ ràng

của sự truyền tải lại).

Topic 28: Improving-RTT-Estimates, GV: PGS. TS. Nguyễn Đình Việt10/24

3. SAMPLING ROUND-TRIP TIMES (LẤY MẪU RTT (RTT-thời gian trễ trọn vòng))

Page 11: 28 K19T1 Improving RTT Estimate&&

3.1 Tính toán trên lần truyền đầu tiên

Topic 28: Improving-RTT-Estimates, GV: PGS. TS. Nguyễn Đình Việt11/24

Page 12: 28 K19T1 Improving RTT Estimate&&

Topic 28: Improving-RTT-Estimates, GV: PGS. TS. Nguyễn Đình Việt12/24

3.1 Tính toán trên lần truyền đầu tiên

Page 13: 28 K19T1 Improving RTT Estimate&&

3.1 Tính toán trên lần truyền đầu tiên

Topic 28: Improving-RTT-Estimates, GV: PGS. TS. Nguyễn Đình Việt13/24

Page 14: 28 K19T1 Improving RTT Estimate&&

3.2 Tính toán trên lần truyền gần nhất

Topic 28: Improving-RTT-Estimates, GV: PGS. TS. Nguyễn Đình Việt14/24

Page 15: 28 K19T1 Improving RTT Estimate&&

3.2 Tính toán trên lần truyền gần nhất

Topic 28: Improving-RTT-Estimates, GV: PGS. TS. Nguyễn Đình Việt15/24

Page 16: 28 K19T1 Improving RTT Estimate&&

3.2 Tính toán trên lần truyền gần nhất

• Điều đó khiến cho SRTT giảm, làm giảm RTO, và làm tăng khả năng một gói dữ liệu

được báo nhận ngay sau khi RTO hết hiệu lực.

• SRTT ổn định tại một giá trị ước tính thấp rất vô lý.

• Sự truyền tải lại thông tin dữ liệu một cách không cần thiết xuất hiện liên tục, lưu

lượng có ích giảm nhanh chong và băng thông mạng bị lãng phí.

• Quan sát thấy vấn đề giảm SRTT có thể tránh được nếu RTO được đặt rất cao, cao

đến mức không có gói dữ liệu nào có thể sống lâu hơn khoảng thời gian đó mà không

hồi đáp.

• Tuy nhiên, để đảm bảo lưu lượng cao, RTO không thể cao hơn SRTT. Một thuật toán

đòi hỏi giá trị RTO rất cao sẽ cho hiệu suất không chấp nhận được qua một đường

dẫn hao tổn.

Topic 28: Improving-RTT-Estimates, GV: PGS. TS. Nguyễn Đình Việt16/24

Page 17: 28 K19T1 Improving RTT Estimate&&

3.3 Bỏ qua thời gian khứ hồi đối với các gói tin đã được truyền lại

Bỏ qua các mẫu RTT bị làm hỏng bởi việc truyền lại Phương pháp làm việc này cung cấp thời gian khứ hồi thực không bao giờ tăng

nhanh hơn thuật toán có thể thích ứng Nếu có một sự gia tăng bất ngờ RTT và độ trễ đường dẫn mới lớn hơn RTO, thì tất

cả các mẫu sẽ bị loại bỏ. Mỗi gói tin sẽ được truyền lại trước khi tín hiệu biên nhận trở lại

Nếu RTO là hợp lý, thì việc RTT bất ngờ vượt quá RTO là ít xảy ra Hậu quả của RTT vượt quá RTO

Bên gửi bị cản trở bởi một RTO nhỏ một cách phi thực tế, có rất ít cơ hội hoặc không có cơ hội sửa chữa

Có rất nhiều sự truyền lại không cần thiết, băng thông giảm mạnh và dung lượng mạng bị lãng phí

Topic 28: Improving-RTT-Estimates, GV: PGS. TS. Nguyễn Đình Việt17/24

Page 18: 28 K19T1 Improving RTT Estimate&&

3.4 Thuật toán Karn

Thuật toán của Karn (gọi tắt là thuật toán Karn) giải quyết vấn đề bằng cách bỏ qua thời gian khứ hồi (RTT) của các gói tin truyền lại.

Quan điểm chủ yếu của thuật toán Karn là sử dụng RTO back-off để thu các số đo thời gian khứ hồi chính xác không bị hỏng bởi sự mơ hồ. Bao gồm các quy tắc sau:

Quy tắc 1: Khi một tín hiệu biên nhận tới một gói tin được gửi hơn một lần (tức là, được truyền lại hơn một lần), bỏ qua bất kỳ phép đo khứ hồi dựa vào gói tin này, do đó tránh được vấn đề truyền lại mơ hồ.

Quy tắc 2: RTO được back-off cho gói tin này được giữ trong gói tin tiếp theo. Chỉ khi nó được báo nhận không có sự truyền lại xen vào, RTO sẽ được tính lại từ SRTT

Topic 28: Improving-RTT-Estimates, GV: PGS. TS. Nguyễn Đình Việt18/24

Page 19: 28 K19T1 Improving RTT Estimate&&

Thuật toán Karn

SRTT sẽ hội tụ tới một giá trị đúng và sự truyền lại không cần thiết sẽ dừng Để tránh những truyền lại không cần thiết, RTO >> new_RTT, để đạt được giá trị

new_RTT thì SRTT ≥ new_RTT, s/ β (s không thay đổi). Đưa ra new_RTT có n mẫu hợp lệ, trong đó n là giá trị tối thiểu mà bất đẳng thức dưới đây theo new_RTT, old_SRTT là đúng:

Trong đó:

- s : new_RTT (s không đổi)

- β : RTO

- n : số mẫu hợp lệ, trong đó n là giá trị tối thiểu

- z : old_SRTT Sử dụng giá trị tiêu biểu α=0.875 và β=2, n chỉ là 6, vì số lượng các mẫu hợp lệ yêu

cầu nhỏ, thì sự hội tụ thường nhanh

Topic 28: Improving-RTT-Estimates, GV: PGS. TS. Nguyễn Đình Việt19/24

Page 20: 28 K19T1 Improving RTT Estimate&&

Thuật toán Karn

Trong trường hợp xấu nhất, s – z ≈ s (tức là s››z), do đó có thể bỏ qua z, chia 2 về bất đẳng thức cho s, ta được:

Một thực thi TCP sẽ sử dụng thuật toán Karn và bộ lọc phi tuyến của Mill đã được sử dụng nhiều trong môi trường tệ nhất đã từng sử dụng để truyền các gói tin IP: máy phát gói tin không chuyên.

Mặc dù tỉ lệ mất mát gói tin thường vượt quá 50%, các giá trị SRTT còn lại khá ổn định, chỉ thay đổi để đáp ứng với sự thay đổi thực trong thời gian khứ hồi. Các gói tin bị thất lạc do nhiễu rời khỏi SRTT không bị ảnh hưởng.

Topic 28: Improving-RTT-Estimates, GV: PGS. TS. Nguyễn Đình Việt20/24

Page 21: 28 K19T1 Improving RTT Estimate&&

Triển khai thuật toán Karn

Triển khai minh họa thuật toán Karn cho một TCP chỉ với một gói tin tồn tại trong một thời gian.

Các biến: Thời gian khứ hồi (rtt) Thời gian khứ hồi đã làm mịn (srtt) Thời gian chờ khứ hồi hiện hành (rto) Số lượng truyền lại các gói tin hiện hành (rxmit) Khối kết nối TCP (tcp) Thiết lập thời gian chờ khứ hồi (rto_set)

Topic 28: Improving-RTT-Estimates, GV: PGS. TS. Nguyễn Đình Việt21/24

Page 22: 28 K19T1 Improving RTT Estimate&&

Triển khai thuật toán Karn

Khi truyền một gói tin TCP thay vì thiết lập RTO thành một hàm của srtt, chúng ta sẽ thiết lập thành rto_set

/*Thiết lập thời gian chờ và đếm số truyền lại cụ thể*/

Sửa đổi biên nhận TCP thành cập nhật srtt và rto_set, nếu không có truyền lại./*xem nếu gói tin biên nhận được hẹn giờ đã được truyền*/

/* Cập nhật srtt và rto_set

rtt chứa thời gian khứ hồi đã đo

*/

Topic 28: Improving-RTT-Estimates, GV: PGS. TS. Nguyễn Đình Việt22/24

Page 23: 28 K19T1 Improving RTT Estimate&&

Triển khai thuật toán Karn

Nếu có một thời gian chờ truyền lại, chúng ta backoff theo cấp số nhân, rto và rto_set:/*

* thời gian chờ truyền lại: backoff rto và ghi nhận trong rto mới đã backoff

* rto_set có khả năng được sử dụng bởi gói tin kế tiếp

*/

Hàm backoff, thực hiện backoff theo cấp số nhân của thời gian chờ khứ hồi

Topic 28: Improving-RTT-Estimates, GV: PGS. TS. Nguyễn Đình Việt23/110

Page 24: 28 K19T1 Improving RTT Estimate&&

4. Phương pháp lấy mẫu hoàn hảo

Hàm lấy mẫu là một logic, trả về giá trị 0 nếu mẫu được lấy từ tín hiệu báo nhận của một phiên truyền lại và ≠ 0 trong các trường hợp khác.

Các phương pháp lấy mẫu chỉ sử dụng các mẫu mà ≠ 0 ước tính thời gian giữa phiên truyền đầu tiên của gói tin và tín hiệu biên nhận của phiên truyền đầu tiên đó.

Vấn đề là các phương pháp lấy mẫu không đủ xấp xỉ và bao gồm nhiều mẫu xấu hoặc thừa nhận khả năng loại trừ tất cả các mẫu xấu và mẫu tốt.

Thuật toán Karn là một gần đúng tốt của hàm hoàn hảo, , vì nó chỉ chấp nhận các mẫu tốt và sử dụng chiến thuật truyền lại back off để chắc chắn các mẫu tốt sẽ sẵn sàng thậm chí nếu thời gian khứ hồi tăng đáng kể.

Như vậy, thời gian khứ hồi có thể lấy mẫu chính xác.

Topic 28: Improving-RTT-Estimates, GV: PGS. TS. Nguyễn Đình Việt24/24