Điều đó nói rằng mạng Internet cố gắng tốt nhất để di chuyển mỗi gói dữ liệu từ nguồn đến đích càng nhanh càng tốt. Tuy nhiên, dịch vụ best-effort không thực hiện bất kỳ lời hứa nào về mức độ chậm trễ từ nguồn đến đích cho một gói tin riêng lẻ, hoặc theo mức độ biến động của gói tin và mất gói trong luồng truyền gói tin.
Các ứng dụng đa phương tiện tương tác trên thời gian thực, như điện thoại Internet và hội nghị truyền hình trực tuyến, ảnh hưởng sâu sắc đến độ trễ gói tin, sự biến động và sự mất mát. May mắn thay, các nhà thiết kế của các ứng dụng này có thể đưa ra một số cơ chế hữu ích có thể bảo vệ tốt âm thanh và video miễn là độ trễ, sự biến động và sự mất mát không quá cao. Trong phần này chúng ta xem xét một số các cơ chế này. Để thảo luận được cụ thể, chúng ta thảo luận về những cơ chế trong bối cảnh của một ứng dụng điện thoại Internet, được mô tả trong đoạn dưới dây. Tình huống tương tự như cho ứng dụng hội nghị truyền hình trực tuyến [Bolot 1994].
Loa trong ứng dụng điện thoại Internet của chúng ta tạo ra một tín hiệu âm thanh xen kẻ bao gồm giai đoạn đàm thoại tăng vọt và giai đoạn im lặng. Để tiết kiệm băng thông, ứng dụng điện thoại Internet của chúng ta chỉ tạo ra các gói tin trong giai đoạn đàm thoại tăng vọt. Trong giai đoạn bứt phá của cuộc trò chuyện người gửi tạo ra byte với nhịp độ 8 Kbytes mỗi giây, và cứ mỗi 20 mili giây người gửi tập hợp các byte vào một đoạn. Như vậy số lượng các byte trong một đoạn (20 msecs)*(8 Kbytes/giây) = 160 bytes. Một tiêu đề đặc biệt được gắn liền với mỗi đoạn, nội dung của nó được thảo luận dưới đây. Các đoạn cùng với tiêu đề của nó được đóng gói trong một phân đoạn UDP, và sau đó gói dữ liệu UDP được gửi vào giao diện socket. Như vậy, trong một gia đoạn bứt phá của cuộc trò chuyện thì một đoạn UDP sẽ được gửi mỗi 20 mili giây.
Nếu mỗi gói tin gửi đến người nhận (không mất mát) và một hằng số độ trễ nhỏ từ nguồn đến đích, sau đó các gói tin đi đến người nhận định kỳ mỗi 20 mili giây trong giai đoạn bứt phá của cuộc trò chuyện. Trong những điều kiện lý tưởng, người nhận có
thể chỉ đơn giản là có thể phát lại từng đoạn ngay sau khi nó đến. Nhưng không may, một vài gói tin có thể bị mất và hầu hết các gói tin sẽ không có một sự trì hoãn cố định từ nguồn đến đích nào, dù chỉ là một sự tắc nghẽn Internet nhẹ. Vì lý do này , người nhận phải quan tâm nhiều hơn trong (i) xác định khi phát lại một đoạn, và (ii) xác định phải làm gì với một đoạn bị mất.
6.3.1. Những hạn chế của một dịch vụ Best-Effort
Các dịch vụ best-effort có thể dẫn đến sự mất mát gói tin, sự trì hoãn từ nguồn đến đích quá mức, và sự biến động. Để kiểm tra lại, bây giờ chúng ta đi vào những vấn đề chi tiết.
Sự mất mát gói tin
Xem xét một trong những gói dữ liệu UDP được tạo ra bởi ứng dụng điện thoại Internet. Phân đoạn UDP được đóng gói trong 1 gói dữ liệu IP và gói dữ liệu IP này truyền thông qua mạng đến với người nhận. Như gói dữ liệu đi lang thang qua mạng, nó đi qua bộ đệm (tức là, hàng đợi) trong các bộ định tuyến để truy cập các liên kết ngoài. Có thế là một hoặc nhiều bộ đệm trong các tuyến đường từ người gửi đến người nhận là đầy đủ và không thể thừa nhận các gói dữ liệu IP. Trong trường hợp này, gói dữ liệu IP bị loại bỏ và trở thành một gói tin bị mất. Nó không bao giờ đến được ứng dụng nhận.
Mất mát có thể được loại bỏ bằng cách gửi các gói tin qua giao thức TCP chứ không phải trên UDP. Nhớ rằng TCP truyền lại các gói tin không đến được đích. Tuy nhiên, cơ chế truyền lại nói chung là không thể chấp nhận để tương tác được đối với ứng dụng âm thanh thời gian thực. Chẳng hạn như điện thoại Internet, vì chúng làm tăng sự chậm trễ từ nguồn đến đích [Bolot 1996]. Hơn nữa, do TCP kiểm soát tắt nghẽn, sau khi mất gói tin tốc độ truyền tin ở người gửi có thể bị giảm xuống một mức thấp hơn so với tỷ lệ nhận ở người nhận. Điều này có thể có tác động nghiêm trọng đối với tính dễ hiểu của âm thanh ở người nhận. Vì những lý do trên, hầu hết các ứng dụng điện thoại Internet hiện nay chạy trên UDP và có quan tâm đến sự mất mát gói tin.
Nhưng mất gói tin không nhất thiết là nghiêm trọng như người ta có thể nghĩ. Trên thực tế, tỷ lệ mất gói tin từ 1% cho đến 20% có thể được chấp nhận, tùy thuộc
vào cách âm thanh là được mã hóa và truyền đi, và làm các nào sự mất mát được che giấu tại người nhận. Ví dụ, việc sửa lỗi (FEC) có thể giúp che giấu sự mất mát gói tin. Như chúng ta sẽ thấy dưới đây, với thông tin dư thừa FEC được truyền cùng với thông tin gốc do đó một vài dữ liệu gốc bị mất có thể được phục hồi từ những thông tin dư thừa. Tuy nhiên, nếu một hoặc nhiều hơn các liên kết giữa người gửi và người nhận bị tắc nghẽn, và mất mát gói tin vượt quá 10-20%, sau đó thực sự là không có gì có thể được hoàn thành đề đạt được chất lượng âm thanh có thể chấp nhận được. Dịch vụ Best-effort vẫn có hạn chế của nó.
Độ trễ từ nguồn đến đích
Độ trễ từ nguồn đến đích là sự tích tụ xử lý và hàng đợi chậm trễ trong bộ các bộ định tuyến, độ trễ truyền tải, và độ trễ xử lý của hệ thống cuối. Cho các ứng dụng âm thanh tương tác cao, như điện thoại Internet, độ trễ từ nguồn đến đích nhỏ hơn 150 mili giây không được nhận thấy bằng sự lắng nghe của con người; độ trễ từ 150 đến 400 mili giây có thể chấp nhận được nhưng không lý tưởng, và độ trễ quá 400 mili giây cho kết quả trong cuộc hội thoại bằng giọng nói.
Người nhận trong ứng dụng điện thoại Internet thông thường sẽ bỏ qua bất kỳ gói tin nào bị trì hoãn hơn 1 ngưỡng nào đó. Do đó, các gói tin bị trì hoãn hơn ngưỡng cho phép sẽ bị mất hiệu quả.
Biến động trễ
Một trong những thành phần của độ trễ từ nguồn đến đích là độ trễ hàng đợi ngẫu nhiên trong các bộ định tuyến. Vì những sự chậm trễ hàng đợi ngẫu nhiên trong hệ thống, thời gian từ khi gói tin được tạo ra tại nguồn cho đến khi nó nhận được tại người nhận có thể dao động từ gói tin đến gói tin. Phenonenom này được gọi là biến động.
Ví dụ, xem xét hai gói tin liên tiếp trong giai đoạn tăng vọt của cuộc nói chuyện trong ứng dụng điện thoại Internet của chúng tôi. Người gửi gửi gói tin thứ 2 trong 20 mili giây sau khi gửi gói tin đầu tiên. Nhưng ở người nhận khoảng cách giữa các gói tin có thể trở nên lớn hơn 20 ms. Để thấy điều này, giả sử gói tin đầu tiên được gửi đến hàng đợi gần như rỗng tại bộ định tuyến, nhưng ngay trước khi gói tin thứ hai đến hàng đợi, một số lượng lớn các gói tin từ các nguồn khác đến để vào cùng một hàng
đợi giống nhau. Vì gói tin thứ 2 chịu một sự trì hoãn tại hàng đợi lớn, gói tin đầu tiên và thứ hai cách nhau hơn 20 mili giây. (Trong thực tế, khoảng cách giữa 2 gói tin liên tiếp có thể trở thành 1 giây hoặc nhiều hơn). Khoảng cách giữa các gói tin liên tiếp cũng có thể trở thành ít hơn 20 mili giây. Để thầy điều này, ta lại xem xét hai gói liên tiếp trong một vòng tăng vọt âm thanh cuộc trò chuyện. Giả sử gói tin đầu tiên tham gia vào phần cuối của hàng đợi với số số lượng lớn các gói tin, và gói tin thứ hai đến hàng đợi trước khi các gói tin từ các nguồn khac đến hàng đợi. Do đó, hai gói tin của chúng tôi thấy chính mình ngay đằng sau mỗi gói khác trong hàng đợi. Nếu thời gian cần để truyền gói tin trên các liên kết ra ngoài từ router là ít hơn 20 mili giây, thì sau đó các gói tin đầu tiên và thứ hai có khoảng cách ít hơn 20 mili giây.
Tình huống tương tự với lái xe ô tô trên đường. Giả sử bạn và bạn của bạn là mỗi lái xe trong ô tô riêng của bạn từ San Diego đến Phoenix. Giả sử bạn và bạn của bạn có kiểu lái xe tương tự, và rằng cả hai lái ở tốc độc 100km/giờ, giao thông phép. Cuối cùng, giả sử bạn của bạn bắt đầu tiến hành trước bạn một giờ. Sau đó, tùy thuộc vào lưu lượng can thiệp, bạn có thể đến Phoenix nhiều hoặc ít hơn 1 giờ sau bạn của bạn.
Nếu người nhận bỏ qua sự có mặt của sự biến động, và phát ra khối ngay sau khi chúng đến nơi, sau đó kết quả chất lượng âm thanh có thể dễ dàng trở nên khó hiểu ở người nhận. May mắn là, sự biến động thường có thể được loại bỏ bằng cách sử dụng số thứ tự, nhãn thời gian và độ trễ bên ngoài,như chúng tôi thảo luận dưới đây.
6.3.2. Loại bỏ biến động nhận được cho âm thanh
Cho ứng dụng bằng giọng nói như điện thoại Internet hoặc âm thanh theo yêu cầu, người nhận phải cố gắng cung cấp đồng bộ khung tin khối tiếng nói với sự có mặt của biến động mạng ngẫu nhiên. Điều này thường được thực hiện bằng cách kết hợp ba cơ chế sau:
- Cách thêm một số thứ tự trên mỗi đoạn. Người gửi tăng giá trị số thứ tự của mỗi gói tin mà nó tạo ra.
- Cách thêm một nhãn thời gian trên từng đoạn. Các nhãn trên mỗi khối mà người gửi cùng với thời gian từ đó các đoạn được tạo ra.
- Trì hoãn phát lại các đoạn ở người nhận. Sự trì hoãn phát lại của các đoạn âm thanh phải đủ lâu để hầu hết các gói tin nhận được trước khi thời gian
phát lại dự kiến của chúng. Trì hoãn phát lại này vừa có thể cố định trong suốt thời gian của hội nghị, hay có thể thay đổi một cách thích ứng trong suốt thời gian hoạt động của hội nghị. Các gói tin không đến trước thời gian dự kiến phát lại của chúng được coi là bị mất và lãng quên, như đã đề cập ở trên, người nhận có thể sử dụng một số hình thức của hình thức nội suy bài nói để che giấu đi sự mất mát.
Số thứ tự và nhãn thời gian chiếm lĩnh trong tiêu đề của các khối âm thanh. Một định dạng chuẩn hóa cho các tiêu đề của âm thanh được mô tả trong phần tiếp theo.
Bây giờ chúng ta thảo luận về hoạt động của ba cơ chế này, khi kết hợp, có thể làm giảm hoặc thậm chí loại bỏ những ảnh hưởng của biến động. Chúng ta kiểm tra hai kế hoạch phát lại: trì hoãn phát lại cố định và thích ứng trì hoãn phát lại.
Trì hoãn phát lại cố định
Với chiến lược trì hoãn cố định, người nhận cố gắng phát lại mỗi khối chính xác q mili giây sau khi khối này được tạo ra. Vì vậy, nếu một khối là nhãn thời gian tại thời điểm t, người nhận phát ra khối tại thời điểm t+q, giả sử các khối đã đến theo dự kiến phát lại tại thời điểm t+q. Các gói tin đến sau lần phát lại theo kế hoạch của chúng sẽ bị loại bỏ và được coi là bị mất. (adsbygoogle = window.adsbygoogle || []).push({});
Lưu ý rằng số thứ tự không cần thiết cho chiên lược trì hoãn cố định này. Cũng lưu ý rằng ngay cả trong sự có mặt thỉnh thoảng của gói tin bị mất, chúng ta vẫn có thể tiếp tục vận hoạt động chiến lược trì hoãn cố định.
Một lựa chọn tốt của q là gì? Điện thoại Internet có thể hổ trợ trì hoãn lên đến khoảng 400 mili giây, mặc dù trải nghiệm tương tác thỏa mãn hơn là đạt được với các giá trị nhỏ hơn của q. Mặc khác, nếu q được làm nhỏ hơn nhiều so với 400 mili giây, sau đó nhiều gói tin có thể bỏ lỡ thời gian phát lại theo kế hoạch của chúng do mạng gây ra trì hoãn biến động. Đại khái nếu có sự thay đổi lớn trong trì hoãn end-to-end là điển hình, tốt nhất là sử dụng q lớn, mặt khác, nếu trì hoãn là nhỏ và các biến thể chậm trễ cũng là nhỏ, nó thích hợp hơn để sử dụng một q nhỏ, có lẽ ít hơn 150 mili giây.
Sự cân bằng giữa sự trì hoãn phát lại và mất gói tin được minh họa trong hình 6.3-1. Số liệu này cho thấy thời gian mà gói tin được tạo ra và diễn ra trong một cuộc nói chuyện tăng vọt duy nhất. Hai sự trì hoãn phát lại ban đầu riêng biệt được xem xét.
Khi thể hiện bằng bên trái của bậc thang nhất, người gửi tạo ra gói tin đều nhau – cụ thể, mỗi 20 mili giây. Gói đầu tiên trong bài nói chuyện bứt phá này nhận được vào thời điểm r. Như thể hiện trong hình, lượt đến của các gói tin tiếp theo không đều nhau do biến động mạng.
Đối với lịch trình phát lại đầu tiên, sự trì hoãn phát lại cố định được thiết lập để p-r. Với lịch trình này, gói tin thứ tư không đến bởi thời gian phát lại theo lịch trình, và người nhận coi nó bị mất.Đối với lịch trình phát lại thứ hai, sự trì hoãn phát lại ban đầu cố định được thiết lập để p’-r. Cho lịch trình này tất cả các gói tin đến trước khi thời gian lịch trình phát lại của chúng, và do đó không bị mất.
Hình 6.3 - : Mất gói tin vì trì hoãn phát lại cố định khác.
Thích ứng với độ trễ phát lại
Ví dụ trên cho thấy một điều quan trọng của sự cân bằng trì hoãn – mất phát sinh khi thiết kế một chiến lược phát lại với sự trì hoãn phát lại cố định. Bằng cách làm cho sự chậm trễ phát xạ lớn ban đầu, hầu hết các gói dữ liệu sẽ làm cho thời hạn của họ và do đó sẽ có mất mát không đáng kể, tuy nhiên, cho tương tác các dịch vụ như điện thoại Internet, trì hoãn lâu dài có thể trở thành khó chịu nếu không không thể chấp nhận. Lý tưởng nhất, chúng tôi muốn sự chậm trễ phát xạ phải được giảm thiểu chịu sự ràng buộc mà mất được dưới một vài phần trăm.
Một cách tự nhiên để đối phó với sự cân bằng này là để ước tính sự chậm trễ mạng và phương sai của sự chậm trễ mạng, và để phù hợp điều chỉnh sự chậm trễ phát xạ ở đầu mỗi talkspurt. Điều chỉnh thích nghi này của sự chậm trễ phát xạ vào đầu của talkspurts sẽ làm cho thời gian im lặng của người gửi được nén và kéo dài, tuy nhiên, nén và kéo dài của sự im lặng bằng một số tiền nhỏ là không đáng chú ý trong bài phát biểu.
Trong bài báo [Ramjee 1994], bây giờ chúng ta mô tả một thuật toán chung chung mà người nhận có thể sử dụng để điều chỉnh thích nghi chậm trễ phát xạ của nó. Này kết thúc, chúng ta hãy
= nhãn thời gian của gói tin thứ i = thời gian gói tin được tạo ra bời người gửi
= thời gian gói tin thứ i nhận được
= thời gian gói tin thứ i phát lại
Sự trì hoãn mạng end-to-end của gói tin thứ i là ri-ti. Do biến động mạng, sự trì hoãn này sẽ thay đổi từ gói đến gói. Để di biểu thị một ước tính của sự trì hoãn mạng trung bình sau khi nhận được các gói tin thứ i. Ước tính này được xây dựng từ các nhãn thời gian như sau:
Nơi u là một hằng số cố định (ví dụ, u=0.1). Do đó di là một trung bình vuốt của mạng lưới quan sát chậm r1 - t1, ..., ri - ti; Dự toán đặt trọng lượng thêm về sự