Đo độ trễ mạng một chiều

Đây là một câu đố về đo độ trễ mạng mà tôi tạo ra. Tôi tin rằng giải pháp là không thể, nhưng bạn bè không đồng ý. Tôi đang tìm kiếm lời giải thích thuyết phục theo cách nào. (Mặc dù nó được đặt ra như một câu đố, tôi nghĩ rằng nó phù hợp trên trang web này vì khả năng ứng dụng vào thiết kế và kinh nghiệm của các giao thức truyền thông như trong các trò chơi trực tuyến, không đề cập đến NTP.)

Giả sử hai robot ở trong hai phòng, được kết nối bởi một mạng có độ trễ một chiều khác nhau như trong hình bên dưới. Khi robot A gửi tin nhắn cho robot B, phải mất 3 giây để nó đến, nhưng khi robot B gửi tin nhắn cho robot A thì phải mất 1 giây để đến nơi. Độ trễ không bao giờ thay đổi.

Các robot giống hệt nhau và không có đồng hồ dùng chung, mặc dù chúng có thể đo thời gian trôi qua (ví dụ: chúng có đồng hồ bấm giờ). Họ không biết ai trong số họ là robot A (có tin nhắn bị trễ 3 giây) và ai là robot B (có tin nhắn bị chậm 1 giây).

Một giao thức để khám phá thời gian khứ hồi là:

whenReceive(TICK).then(send TOCK)

// Wait for other other robot to wake up
send READY
await READY
send READY

// Measure RTT
t0 = startStopWatch()
send TICK
await TOCK
t1 = stopStopWatch()
rtt = t1 - t0  //ends up equalling 4 seconds

Có một giao thức để xác định sự chậm trễ chuyến đi một chiều? Các robot có thể phát hiện ra cái nào trong số chúng có độ trễ gửi tin nhắn dài hơn không?

Sơ đồ sau đây, từ một bài đăng trên blog tôi đã viết , là một bằng chứng trực quan mà không thể:

Lưu ý cách thời gian đến của gói ở mỗi bên giữ nguyên, ngay cả khi độ trễ một chiều thay đổi (và thậm chí trở nên âm!). Gói đầu tiên luôn đến máy chủ lúc 1,5 giây trên đồng hồ của máy chủ, gói thứ hai luôn đến máy khách lúc 2 giây trên đồng hồ của máy khách, v.v. Nội dung gói và thời gian đến địa phương là những thứ duy nhất mà giao thức có thể dựa vào, nhưng nội dung và thời gian đến có thể được giữ không đổi vì sự bất đối xứng thay đổi bằng cách thay đổi độ lệch đồng hồ ban đầu.

Về cơ bản, sự bất đối xứng trong độ trễ một chiều trông giống hệt như độ lệch của đồng hồ. Vì vấn đề nói rằng chúng ta không bắt đầu biết về độ lệch đồng hồ ban đầu hoặc độ bất đối xứng độ trễ một chiều và sự khác nhau trông giống như thay đổi cái khác để hiệu ứng của chúng không thể phân biệt được, chúng ta không thể tách rời những đóng góp của chúng để giải quyết bất đối xứng độ trễ một chiều. Điều đó là không thể.

Chính thức hơn, bạn không thể giải quyết độ dài cạnh khi chỉ đưa ra độ dài của chu kỳ. Cơ sở chu kỳ có độ tự do, tương ứng với n - 1 xiên đồng hồ không xác định so với một trong những người tham gia. Bạn luôn có thể ẩn độ trễ một chiều, ngay cả khi có nhiều người tham gia:$n-1$$n-1$

Nếu bạn không quá thiên về trực quan, tôi có một lập luận trực quan khác. Hãy tưởng tượng một cổng thông tin thời gian đến một trăm năm trong tương lai. Khi bạn trò chuyện với ai đó ở phía bên kia, bạn nhận ra cuộc trò chuyện là hoàn toàn bình thường mặc dù sự bất cân xứng trăm năm trong sự chậm trễ một chiều. Bất kỳ hiệu ứng có thể quan sát sẽ là rõ ràng trên quy mô đó!

Tôi nghĩ rằng không thể tìm ra độ trễ một chiều chỉ bằng cách so sánh đồng hồ bấm giờ.

$A$$B$$C_{A1}$
$B$$C_{B1}=1$
$A$$C_{A2}=9$
$B$$C_{B2}=5$
$A$$B$

Có lẽ nếu bạn làm cho nó một câu hỏi tiền thưởng ai đó sẽ crack nó. Cho đến lúc đó, danh tiếng.

Tôi đã tìm thấy một cách để CẢ HAI khám phá nút nào là ai (tức là ai có độ trễ tin nhắn dài hơn) VÀ ước tính độ trễ chuyến đi một chiều. Trong khi các câu trả lời khác là chính xác, họ CHỈ xem xét phép đo đồng hồ trực tiếp tiếp cận mà tất nhiên không thể hoạt động. Tuy nhiên như tôi đang chứng minh ở đây, đây chỉ là một phần của câu chuyện vì đây là thuật toán làm việc của tôi cho phần trên:

Giả sử như trong cuộc sống thực:

• Liên kết của băng thông hữu hạn b

• Mỗi nút có địa chỉ duy nhất (ví dụ A và B)

• Kích thước gói p nhỏ hơn nhiều so với sản phẩm độ trễ băng thông *

• Các nút A và B có thể lấp đầy kênh

• Nút có một ) (ngẫu nhiên chức năng

Mỗi nút lấp đầy kênh với các gói riêng (được đánh dấu A hoặc B tương ứng) HOẶC chuyển tiếp các gói mà nó nhận được từ các nút khác như sau:

Always fill the channel with my own packets except:
if I receive a packet from another node then
   Randomly choose to 
          either forward that packet from the other node
          or discard that packet and forward my own packet

Giải thích trực quan Vì sản phẩm độ trễ băng thông * của A cao hơn (vì độ trễ cao hơn) A sẽ quản lý để có nhiều gói tin nhận được hơn B, do đó mỗi Node có thể biết họ là ai trong sơ đồ .

Hơn nữa, với thời gian hội tụ đủ để chạy trên thuật toán, tỷ lệ các gói từ A đến B sẽ biểu thị tỷ lệ trễ RTT thực tế của A đến B và do đó OTT mong muốn .

NỀN TẢNG KẾT QUẢ ĐƠN GIẢN Dưới đây là một mô phỏng chứng minh điều trên và cho thấy cách A hội tụ thành công về độ trễ 3 giây và B hội tụ khoảng 1 giây trễ:

Giải thích về Hình: Mỗi dòng biểu thị 1 giây thời gian (kích thước gói được chọn để có thời gian truyền 1 giây cho rõ ràng). Lưu ý rằng mỗi nút có thể bắt đầu thuật toán bất cứ lúc nào không theo bất kỳ trình tự hoặc thời gian cụ thể nào. Các cột như sau:

• NODE A nhận được: Nút A nhìn thấy gì ở phía nhận của nó (đây cũng là P4 bên dưới)

• NODE A tiêm: Nút A gửi đi (lưu ý đây là A hoặc ngẫu nhiên A hoặc B)

• P1, P2, P3: Ba gói đang truyền (theo thứ tự) giữa A và B (truyền 1 giây có nghĩa là 3 gói đang truyền trong thời gian trễ là 3)

• NODE B nhận được: Những gì B nhìn thấy ở phía nhận của nó (đây là P3)

• NODE B tiêm: Những gì B gửi ra (lưu ý đây là B, hoặc ngẫu nhiên A hoặc B mỗi algo)

• P4: Gói tin đang chuyển từ B đến A (xem thêm P1, P2, P3)

• A đếm A: Những gì A đếm cho các gói A mà nó đã thấy

• A đếm B: Những gì A đếm cho các gói B mà nó đã thấy

• B đếm A: B tính gì cho các gói A mà nó đã thấy

• B đếm B: Những gì B tính cho các gói B mà nó đã thấy

• A-> B: Độ trễ mà A ước tính đối với B (tỷ lệ RTT là 4 giây dựa trên các gói được nhìn thấy)

• B-> A: Độ trễ mà B ước tính đối với A (tỷ lệ RTT là 4 giây dựa trên các gói được nhìn thấy)

Như chúng ta có thể thấy cả hai nút hội tụ và ở xung quanh độ trễ thực sự của chúng (thực ra chúng ta không thấy điều đó đối với A vì cần nhiều giây hơn để hội tụ nhưng nó hội tụ cùng một hành vi như B)

Các bộ lọc tốt hơn có thể hội tụ nhanh hơn nhưng chúng ta có thể thấy rõ cả hai cách hội tụ xung quanh các giá trị chính xác cho độ trễ của chúng, do đó chúng có thể biết chính xác độ trễ của chúng (mặc dù tôi chỉ hiển thị ước tính của chúng để minh họa).

Ngoài ra, ngay cả khi băng thông giữa các liên kết khác nhau, phương pháp trên vẫn có thể giữ (mặc dù người ta sẽ phải suy nghĩ về nó chắc chắn hơn) bằng cách sử dụng các cặp gói để tìm ra ước tính băng thông và sau đó chỉ áp dụng cho phương trình tỷ lệ ở trên.

Kết luận Chúng tôi đã cung cấp một thuật toán cho cả A và B để biết vị trí của chúng trong mạng và biết độ trễ của chúng đối với nút khác cho sơ đồ trên. Chúng tôi đã sử dụng phương pháp ước tính đo lường mạng thay vì các phương pháp dựa trên đồng hồ mà thực sự không thể dẫn đến giải pháp do vấn đề đồng bộ hóa đồng hồ đệ quy.

Lưu ý Bây giờ tôi đã chỉnh sửa câu trả lời này cung cấp tất cả các mô phỏng vì không ai tin tôi, tôi đã giải quyết nó cho đến khi bạn có thể thấy trong các bình luận đầu tiên. Hy vọng với những kết quả này, ai đó có thể bị thuyết phục hơn và chấp thuận để giúp mọi người ít nhất tìm thấy một lỗi hoặc tính chính xác trong câu đố đo lường mạng này!

Đây là câu trả lời cho @ user3134164 nhưng quá lớn cho một nhận xét.

$P_x$$x$$R_x$$x$

• $R_1 = (1 - R_2) \times (1 - P_2)$$R_2 = (1 - R_1) \times (1 - P_1)$. Ý tưởng là nếu một robot nhận được một trong các gói của chính nó, điều đó có nghĩa là robot kia đã nhận được nó thay vì một trong các gói của chính nó (do đó$1 - R_2$) và rằng nó vẫn chọn gửi nó thay vì một trong số đó (do đó sản phẩm của $1 - P_2$).
• Điều này đưa ra một hệ thống gồm hai phương trình với hai ẩn số, $R_1$ và $R_2$. Bạn có thể muốn giải quyết nó, nhưng nó không thực sự quan trọng. Trong thực tế, các tỷ lệ bạn đang tìm kiếm tương ứng$\frac{R_1}{1 - R_1}$ và $\frac{R_2}{1 - R_2}$. Như bạn có thể nhận thấy, các thuật ngữ duy nhất xuất hiện trong các biểu thức đó là xác suất mà mỗi robot chọn gói riêng của chúng so với các cụm từ khác. Độ trễ thậm chí không xuất hiện trong công thức đơn giản vì cả hai robot đều bơm ra các gói liên tục, vì vậy cả hai đều liên tục nhận được các gói. Họ thực sự sẽ nhận được các tỷ lệ khác nhau của các gói, nhưng nó sẽ chỉ phụ thuộc vào các xác suất đã nói ở trên.

Đây là lý do tại sao tôi tin rằng điều này sẽ dẫn bạn đến đâu. Xin vui lòng chỉ ra bất kỳ sai lầm tôi có thể đã làm trong lý do này.