scalable low overhead delay estimation yossi cohen advance ip seminar

Scalable Low Overhead Delay Estimation

Yossi Cohen

Advance IP seminar

Topics viewed

IP inefficiency with multiple receivers Multicast overview Multicast delay (RTT) estimation problems Proposed solution

“TV” on the web

What happens when there is a broadcast of the same data to many users (thousands)?

Example : “Madonna online” last month on msn.

The problem

Congestion

Result

Buffering…. Site is overloaded try later…

Multicast Overview

IGMP & SRM

IP Multicast-basic ideas

The last routers before a path split would duplicate the packets.

The packets travel once instead of thousands of times (flash).

Supported by most routers made in the last years (need SW upgrade).

IP Multicast – Advantages/ Disadvantages

Advantages– Less congestion.– Reduce unicast servers load.

Disadvantages– Not reliable (Like UDP)– Needs application that support it.

Why Multicast is not used?

Billing – How should ISPs bill a multicast session?

Application support. Access rights/Security. Since some routers don’t support it there (old

routers or not enabled new routers) there would always be a need for hybrid unicast multicast (HMU). So why not use unicast only.

IGMP

Internet Group Management Protocol The basic Multicast protocol. Described in RFC2933. IP Layer level protocol (with ICMP) Carried in IP datagrams.

IGMP

IGMP defines the multicast group interfaces and the protocols for joining and leaving a multicast group.

Two types of messages: Host message and Router message.

Defines a special group address

Problems with IGMP

IP is a “Best effort” protocol which does not guarantee that the information sent was actually received by the client.

Therefore IGMP is unreliable.

Reliability in multicast

Several algorithms were proposed to solve this problems and create are more reliable Multicast.

SRM, MTCP (Multicast TCP) and RMTP (Reliable Multicast Transport protocol) are “TCP-like” protocol for multicast networks that tries to guarantee delivery.

Scalable low overhead network delay estimation

Problem definitionNetwork ModelBW estimation

In multicast we trust?

In order to evaluate the network bandwidth TCP estimates the RTT. (used in “Window Size” coeff.)

SRM and other “Reliable Multicast” protocols also need accurate and low bandwidth delay estimation method in order to work properly.

Problem definition

“Reliable” multicast protocols needs an accurate low bandwidth delay estimation from each node to each node in a multicast network.

Current methods cost high BW according to the authors multicast network model (Would be calculated soon).

This article suggest a methods to get accurate results with lower bandwidth.

Network Model

• This article assumes a FULL multicast network in which each node multicast to all the others. A clique model.

Model correctness

Most application that use multicast are working in a few->many (forest model) method for example video conferencing, company broadcast, Distance learning etc.

See examples at RealM. this multicast model and the

calculation derived from it are not correct.

(Remarks)

So what have we done? Current multicast application and their delay

estimation protocols are built for a tree/forest model. The article assumes a model that is not used in neither MIB application (VC, DL, broadcast), say there is a huge overhead and try to correct it. If it was truly such a huge overhead don’t you think it would be corrected by now ?! Anyway let’s continue…

BW estimation-Suggested protocol

Current protocol aim to lower the bandwidth needed to 10KB/S which could be acceptable.

Current method – How they work

SRM uses a protocol called session to estimate delay.

Each node periodically multicast last time-stamps received from other nodes.

So each node multicast O(n) timestamps totaling in O(n^2). (according to the network model)

What is suggested?

R

n^2 n (only for delay estimation basic config. stays the same)

(Remarks)

If we look at this model closely and redraw it it is easy to see that the “new” network configuration suggested was actually the tree model…..

Further explanation

One node would be used as a “Reference point”.

Each node send a message to the reference point o(n) and then it multicast all timestamps received to all the nodes o(n) again. So BW consumption is o(n).

This however is not enough to estimate delay between any node to any node.

The Delay estimation protocol

Set-upNode-Node delay estimation

Set-up phase

In this phase each node Q determines the delay from the reference point S to itself, d(q,s).

In order to do that it send it’s current time to the reference point S. S sends the message back with it’s time stamp.

By using the time-stamp diff Q can compute d(Q,S)

QR

S

Delay estimation phase

In this phas each node R determines the delay from each node Q to itself.

d(Q,R) = d(Q,S)+d(S,R) + dmM – (tM-tm)

Explanation:Node Q multicast a probe message containing d(Q,S) (determined in set-up phase) and the local time it send it m.

Tm is the time that node R receives the message.

QR

S

Delay estimation phase-continues

Upon receiving m S multicast M containing tmM the time between receiving and sending m.

froom this we receive d(Q,R) = d(Q,S)+d(S,R) + dmM – (tM-tm)

Time is relative - proof

Let t be the time(in R’s clock) that Q sent message m.

Since m was received in R at tm then t = tm – d(Q,R). Also since M was received in tM then t = tM – d(S,R)-dmM-d(Q,S) tm – d(Q,R) = tM – d(S,R)-dmM-d(Q,S) d(Q,R) = d(Q,S)+d(S,R) + dmM – (tM-tm)

Summery

For each d(Q,R) we used two multicast messages (after the set-up phase). This reduce the BW used to estimate delay from o(n^2) to o(n).