Bảng 1 chỉ ra rằng PPStream chỉ dựa trên TCP. Phần chính yếu của lưu lượng PPLive dựa trên TCP trong khi lưu lượng của SOPCast hầu hết lại dựa trên UDP. TVAnts thì cân đối hơn giữa TCP và UDP. Tất cả các ứng dụng này thông lượng tải về tương đối ổn định và cao hơn một chút so với tốc độ bít của video trong khi thông lượng chiều lên biến động lớn và ở tốc độ cao hơn. Để là ví dụ, hình 2 cho thấy tổng thông lượng tải về và gửi lên đối với TVAnts. Đồ thị biểu diễn của tất cả các ứng dụng khác có thể tìm thấy trong [10]. Các kết quả này đúng như dự kiến bởi lẽ các nút đều cố gắng tải video về ở tốc độ bit ổn định và chúng có năng lực gửi lên rộng rãi.
Hình 4.2: ví dụ về tổng thông lượng tải về và gửi lên đối với ứng dụng TVAnts. Tất cả các ứng dụng đều có cùng mẫu thông lượng này.
Các mẫu lưu lượng:
Các ứng dụng P2P này là các ứng dụng độc quyền riêng nhưng thừa nhận là có dùng các cơ chế hội tụ trong đó các bên ngang hàng trao đổi thông tin về các kiện dữ liệu và về các bên ngang hàng lân cận như dùng trong Donet . Trong mạng lưới P2P như thế, một bên ngang hàng sẽ lặp đi lặp lại việc tìm kiếm các bên ngang hàng khác và sẽ thiết lập các phiên báo hiệu hoặc các phiên video mới. các phiên video thường là có thời gian tồn tại dài bởi lẽ những người dùng muốn xem toàn bộ trận đấu, trong khi các phiên báo hiệu thì thường ngắn hơn về thời gian. Hơn nữa, kích thước các gói luồng video dự kiến là lớn còn kích thước các gói của phiên báo hiệu thì được xác định là ở mức trung bình. Hình 3 hiển thị sự phụ thuộc của kích thước gói trung bình theo độ dài phiên sử dụng thang đo log-log. PPLive (Hình 3(a)) và PPStream (Hình 3(b)) có các mẫu lưu lượng TCP tương tự nhau thế nhưng PPLive còn dùng cả UDP nữa. các phiên UDP của PPLive biến thiên từ ngắn tới dài, nhưng kích thước gói trung bình cảu chúng thì nhỏ và ổn định. Lưu lượng UDP của PPLive vận chuyển các phiên báo hiệu. PPLive và PPStream cho thấy hai tụm trong mẫu lưu lượng TCP của chúng: tụm ở giữa đồ thị là thể hiện các phiên báo hiệu (các gói kích thước nhỏ và thời gian phiên ngắn) và tụm ở phía trên bên phải đồ thị là
của các phiên video (kích thước gói lớn và thời gian phiên dài). PPLive và PPStream dùng TCP để vận chuyển các lưu lượng video và báo hiệu. chúng tôi vẫn đang xem xét sự khác nhau giữa các phiên báo hiệu dựa trên UDP hoặc TCP đối với PPLive. Căn cứ trên mẫu lưu lượng của SOPCast (Hình 3(c)), chúng ta quan sát thấy rằng nó sử dụng hầu như là UDP. Chúng ta vẫn có thể quan sát các tụm ở giữa (báo hiệu) và ở phía trên bên phải (video) của đồ thị nhưng chúng không được hình thành rõ ràng cho lắm. SOPCast chuyển vận lưu lượng cả của báo hiệu và video trên UDP. Chúng tôi hiện có sự phân tích kỹ hơn để hiểu được tại sao có rất ít các phiên dựa trên TCP. So sánh với các ứng dụng được đo khác, mẫu lưu lượng của TVAnts cho thấy một sự cân bằng trong việc sử dụng TCP và UDP (Hình 3(d)). Chúng ta có thể phân biệt được các tụm báo hiệu và video nhưng chúng đều chứa cả lưu lượng TCP và UDP. TVAnts vận chuyển các phiên báo hiệu và video cả trên TCP và UDP. Tuy nhiên, phần lớn hầu hết lưu lượng của TVAnts được vận chuyển bằng TCP (xấp xỉ 75%, bảng 1).
Bảng 2 tổng hợp các quan sát của chúng tôi từ Hình 3: tất cả các ứng dụng được đem đo đều có các mẫu lưu lượng khác nhau. PPStream chỉ sử dụng TCP cho lưu lượng video và báo hiệu trong khi PPLive bổ sung thêm UDP cho một số lưu lượng báo hiệu, còn TVAnts thì dùng cả TCP và UDP cho tất cả các loại lưu lượng, SOPCast thì dùng hầu như toàn bộ là UDP. Đây là một khác biệt quan trọng giữa tất cả các ứng dụng. nếu chúng ta xem xét tất cả các ứng dụng, chúng ta sẽ quan sát thấy rằng lưu lượng video thì hầu hết được vận chuyển bằng TCP, vốn không phải là giao thức dành cho các ứng dụng đa phương tiện và theo thời gian thực. đối với các ứng dụng phát luồng video thông thường trên Internet, TCP có thể được điều chỉnh để đến được với tất cả các kiểu người dùng Internet, ngay cả khi có ở sau bộ lọc hoặc các hệ thống NAT.
Hình 4.3: Kích thước gói trung bình tương ứng với độ dài phiên của các bên ngang hàng
Để đánh giá tổng lượng lưu lượng báo hiệu trong các dấu vết, chúng tôi phân tách các lưu lượng video và báo hiệu bằng một giải thuật nghiệm suy đề xuất trong [6]. Giải thuật này hoạt động như sau: đối với một phiên (có cùng các địa chỉ IP và cổng), chúng tôi đếm số lượng các gói có kích thước lớn hơn hoặc bằng 1000 byte. Nếu một phiên mà có ít nhất 10 gói lớn như thế, nó sẽ được gán cho là một phiên video và chúng tôi sẽ loại bỏ các gói nhỏ (<1000 Byte) khỏi phiên này. Chúng tôi sẽ loại bỏ tất cả các phiên không phải là video từ dấu vết. bảng 3 biểu diễn các kết quả từ giải thuật này đối với bốn dấu vết. tỉ số tổng lượng báo hiệu là khác nhau đối với tất cả các dấu vết (từ 4.1% tới 19.3%). Tổng lượng (báo hiệu) của SOPCast có trọng số lớn hơn các ứng dụng khác còn PPLive thì có tổng lượng báo hiệu thấp nhất. PPStream và TVAnts hầu như có cùng một tỉ số tổng lượng báo hiệu như nhau,
nhưng vào lúc kết thúc thì tổng lượng báo hiệu cần thiết để quản lý mạng P2P là khác nhau.
PPLive và PPStream hẳn là không sử dụng các cơ chế hỗ trợ giống nhau. PPStream và TVAnts có tỉ số tổng lượng báo hiệu tương tự nhau nhưng lại thể hiện các mẫu lưu lượng khác nhau. Các cơ chế hỗ trợ bên dưới của chúng hẳn là cũng khác nhau, như đối với SOPCast, ứng dụng này có tỉ số tổng lượng báo hiệu trọng số lớn hơn và một mẫu lưu lượng riêng biệt. trong các mục tiếp theo, chúng tôi sẽ đưa ra một số chi tiết về các cơ chế hỗ trợ bên dưới được dùng bởi tất cả các ứng dụng đã được giới thiệu.
Bảng 3: Tổng lượng báo hiệu
Các chính sách tải về nội dung video:
Trong mục này, mục đích của chúng tôi là để hiểu làm thế nào các nút của chúng ta có thể tải về nội dung video từ các bên ngang hàng khác trên Internet. Đối với mỗi dấu vết, chúng tôi tính toán lượng dữ liệu mà các nút của chúng ta đã tải xuống từ mỗi bên ngang hàng khác. Chúng tôi đã tách ra lưu lượng của 10 bên ngang hàng hàng đầu (các bên ngang hàng đã gửi đi số lượng dữ liệu nhiều nhất tới các nút của chúng ta trong suốt toàn bộ thời gian theo dõi). Chúng tôi cũng tách ra lưu lượng từ bên ngang hàng hàng đầu cũng theo cùng một cách đó (bên ngang hàng hàng đầu thuộc nhóm 10 bên ngang hàng hàng đầu). trong hình 4, chúng tôi vẽ ra tổng lượng lưu lượng tải về, lưu lượng tải về từ 10 bên ngang hàng hàng đầu tổ hợp và từ các bên ngang hàng hàng đầu. Mỗi giá trị được vẽ ra là một quãng trung bình 60 giây. SOPCast (Hình 4(c)) nhận được không một chút lưu lượng nào phút thứ 130 tới 140, và chúng tôi theo dõi thấy màn hình đen trong suốt quãng thời gian này. Vấn đề này không xảy ra do các vấn đề mạng lưới bởi lẽ PPStream hoạt động tốt trong cùng giai đoạn đó. Nguồn video hẳn là có vấn đề kỹ thuật trong quãng thời gian
này. Tất cả các dấu vết SOPCast của chúng tôi đã thể hiện dạng rắc rối này và chúng tôi giữ chúng lại cho việc nghiên cứu của mình.
Các chính sách tải về đối với tất cả các ứng dụng là hoàn toàn khác nhau do lưu lượng các bên ngang hàng trong nhóm 10 vị trí tổ hợp đứng đầu hay bên ngang hàng hàng đầu không thể hiện cùng một hành trạng. đối với PPLive (HÌnh 4(a)), 10 bên ngang hàng hàng đầu đóng góp phần lớn vào lưu lượng tải về và bên ngang hàng hàng đầu đóng góp gần như tất cả lưu lượng trong quãng thời gian phiên liên lạc của nó. Phiên liên lạc của bên ngang hàng hàng đầu thì tương đối ngắn xét trên tất cả quãng thời gian lần dấu. các quan sát này chỉ báo rằng PPLive lấy nội dung video về từ chỉ một số ít bên ngang hàng tại cùng một thời ddiemr và chuyển đổi định kỳ từ bên ngang hàng này sang bên ngang hàng khác. Nhớ rằng PPLive và PPStream có mẫu lưu lượng gần như là giống nhau (Hình 3(a) 3(b)), thật hứng thú khi quan sát thấy rằng chính sách tải về của PPStream lại trái ngược với của PPLive. Đối với PPStream (Hình 4(b)), các bên ngang hàng ở 10 vị trí đứng đầu không đóng góp một phần lớn vào lưu lượng tải về, bên ngang hàng đứng đầu cũng không. PPStream phải lấy dữ liệu từ nhiều bên ngang hàng trong cùng một thời điểm và các bên ngang hàng của nó có thời gian phiên liên lạc là dài. 10 bên ngang hàng hàng đầu trong SOPCast (Hình 4(c)) đóng góp khoảng một nửa tổng số lưu lượng tải về và bên ngang hàng đứng đầu đóng góp tất cả lưu lượng của 10 bên ngang hàng đó trong quãng thời gian phiên của nó. Một cách nào đó, chính sách tải về của SOPCast trông giống như của PPLive: nó chuyển đổi định kỳ bên ngang hàng cung cấp (nội dung). Tuy nhiên, SOPCast có vẻ như luôn cần nhiều hơn một bên ngang hàng để lấy được nội dung video, so với PPLive là ứng dụng mà một bên ngang hàng duy nhất có thể là bên cung cấp nội dung video duy nhất. Chính sách tải về của TVAnts (Hình 4(d)) có vẻ là sự pha trộn giữa các chính sách của PPStream và SOPCast. Các bên ngang hàng 10 vị trí đứng đầu của TVAnts đóng góp khoảng một nửa tổng lưu lượng tải về (giống như SOPCast), thế nhưng bên ngang hàng đứng đầu không đóng góp phần lớn trong số tổng lưu lượng (giống như PPStream). 10 vị trí đầu các bên ngang hàng của TVAnts không đóng góp ít ỏi như ở PPStream nhưng không kéo dài lâu như bên ngang hàng hàng đầu của PPStream.
Hình 4.4: Các chính sách tải video: tổng lượng lưu lượng, lưu lượng của 10 vị trí bên ngang hàng hàng đầu và lưu lượng của bên ngang hàng đứng đầu.
Thời gian khung đo là 60 giây
Nếu chúng ta tổng hợp các kết quả quan sát, các ứng dụng được giới thiệu ở đây áp dụng các chính sách tải về khác nhau và không dự kiến các bên ngang hàng có cùng năng lực. một số chính sách tải về dự kiến các bên ngang hàng ở lại trong mạng lưới trong một khoảng thời gian dài (như PPStream) hoặc ngắn (như PPLive, SOPCast), hoặc dự kiến một bên ngang hàng có năng lực cao để gửi tất cả nội dung video (PPLive) hoặc là thấp (PPStream, TVAnts). Tùy theo ứng dụng, một bên ngang hàng có thể lấy nội dung video từ chỉ một số ít các bên ngang hàng tại cùng một thời điểm hoặc là từ nhiều bên ngang hàng và độ dài phiên của nó thì biến thiên. Các chính sách tải về khác nhau cho thấy rõ những khác biệt trong việc duy trì một lân cận để một bên ngang hàng có thể lấy được nội dung video về. Điều này sẽ được chỉ ra trong mục tiếp theo.
Trong các hệ thống P2P hội tụ, các bên ngang hàng phải duy trì lân cận các bên ngang hàng để lấy được các kiện dữ liệu từ nhiều bên ngang hàng tại cùng một thời điểm. trong hình 5, chúng tôi vẽ đồ thị thể hiện lân cận các bên ngang hàng tải nội dung video đối với mỗi ứng dụng được duy trì bởi các nút của chúng ta trong toàn bộ thời gian các dấu vết. một bên ngang hàng tải video là một bên ngang hàng gửi nội dung video đến các nút được điều khiển của chúng ta. Trong phần sau đây, chúng tôi sẽ nhắc tới số lượng các bên ngang hàng tải video bằng cái tên VDP. PPLive duy trì một VDP tương đối thấp và không đổi trong khi PPStream có VDP cao và không đổi. VDP của SOPCast có thể cao như của PPStream nhưng biến động rất nhiều. như dự kiến, SOPCast không có VDP nào khi các nút của chúng ta chạy SOPCast không nhận được lưu lượng. VDP của TVAnts thì cao và cũng biến động.
Tất cả các ứng dụng đều duy trì cho các bên ngang hàng được điều khiển của chúng ta (các nút) một lân cận các bên ngang hàng khác nhau, tương ứng với việc các ứng dụng có các chính sách tải về khác nhau để lấy được nội dung video. Như dự kiến, có một tập lớn các bên ngang hàng ổn định đối với PPStream, và chỉ tập hợp thu hẹp hơn dành cho PPLive. SOPCast và TVAnts có VDP cao và biến động. sự biến động VDP được quan sát thấy trên các ứng dụng sử dụng một phần quan trọng lưu lượng UDP (bảng 1). Các biến động VDP này có thể xuất phát từ tính không tin cậy được của UDP, khiến cho có nhiều gói bị mất hơn và buộc bên ngang hàng làm cho VDP của nó luôn luôn thay đổi để lấy được nội dung video.
Thời gian tồn tại của các bên ngang hàng (chia sẻ) nội dung video:
Trong IPTV P2P, các chủ xị đầu cuối (end-host) chịu trách nhiệm lặp các dòng truyền tới mỗi end-host khác. Các end-host không phải là các thực thể sinh ra để ở mãi trong mạng lưới mọi lúc: chúng có thể gia nhập hoặc rời khỏi mạng bất cứ khi nào chúng muốn và có thiên hướng chịu đựng được lỗi. các hệ thống IPTV P2P phải xử lý với việc đến và đi của các bên ngang hàng (một đống hỗn độn các bên ngang hàng). Đó là một vấn đề đầy thử thách bởi vì video trực tiếp phải chú trọng từng khoảnh khắc chơi để đạt được chất lượng chơi trơn tru. Cả một số lượng lớn hỗn độn các bên ngang hàng sẽ có nghĩa là thêm vào độ trễ hay sự biến thiên biến
động đối với việc phân phối gói tin, điều này sẽ làm giảm toàn bộ chất lượng video. Trong mục này, chúng tôi biểu diễn thời gian tồn tại các bên ngang hàng cung cấp nội dung video để chỉ ra sự hỗn độn của các bên ngang hàng. Do các nút của chúng ta chỉ có một tầm nhìn cục bộ về tất cả các bên ngang hàng trong mạng lưới, nên thời gian tồn tại của bên ngang hàng được đinh nghĩa là quãng thời gian giữa lần đầu tiên và lần cuối các nút được điều khiển của chúng ta trao đổi lưu lượng video với một bên ngang hàng khác.
Xem như một ví dụ, hình 6 vẽ đồ thị hàm phân bố tích lũy bù (CCDF) của thời gian tồn tại các bên ngang hàng chia sẻ video của TVAnts. Đối với tất cả các ứng dụng, CCDF của thời gian tồn tại các bên ngang hàng tuân theo phân bố Weibull. Đồ thị của CCDF đối với các ứng dụng khác có thể tìm thấy trong [10]. Các hàm phân bố Weibull được dùng để thích hợp với thời gian tồn tại các bên ngang hàng chia sẻ video được đo được thể hiện trong bảng 4. Nó cũng biểu diễn thời gian tồn tại bên ngang hàng trung bình.
Phân bố Weibull là phân dạng hàm mũ thường được dùng trong kiểm tra độ tin cậy và phân tích lỗi. đối với tất các ứng dụng, đều không có nhiều hơn 10% các bên ngang hàng ở lại trong mạng trong suốt toàn bộ trận đấu. hơn thế nữa, thời gian tồn tại các bên ngang hàng trung bình là khác nhau đối với mỗi ứng dụng và khá xa so với toàn bộ thời gian một trận đấu. việc ra đi của một bên ngang hàng có thể tùy thuộc vào một người dùng khi người đó ngừng xem trận đấu và tùy thuộc vào các cơ chế hoạt động của ứng dụng, bắt buộc một bên ngang hàng phải chuyển từ bên ngang hàng này sang bên ngang hàng khác. Do tất cả các ứng dụng tuân theo phân