telematics 2 - startseite tu ilmenau · pdf filenetwork multicast router actively participate...

Telematics 2 (WS 14/15): 05 – Multicast 1

Telematics 2

Chapter 5Multicast

(Acknowledgement: These slides have been compiled from various sources)


Introduction: Why Multicast /Multicast Applications?

Basic scenario:

Same data sent to multiple receivers

Example Applications:

Video/audio conference

IP TV, Video on Demand

Advertisement, stock quote distribution, distance learning

Synchronizing of distributed database, web sites, etc.

Principal motivations for multicast:

Sender does not need to know all receivers’ addresses

To use bandwidth efficiently

Reduce routing processing


Popular Multicast Example Applications

Video Conference

Distance Learning


Terminology: Unicast vs. Broadcast vs. Multicast

Unicast:

One sender and one receiver

Broadcast:

One sender, all the others as receivers

Multicast:

One sender (potentially many senders), many receivers

You can take broadcast and unicast as two special types of multicast (if you like to think in generalizations...:o)


Multicast: One Sender to Many Receivers

Multicast: Act of sending datagram to multiple receivers with single “transmit” operation

Analogy: One teacher to many students

Question: How to achieve multicast?

Multicast via unicastSource sends N unicast datagrams, one addressed to each of N receivers

Multicast receiver (red)

Not a multicast receiver (grey)

Routersforward unicastdatagrams





Network multicastRouter actively participate in multicast, making copies of packets as needed and forwarding towards multicast receivers

Multicastrouters (red) duplicate and forward multicast datagrams







Application-layer multicastEnd systems involved in multicast copy and forward unicast datagrams among themselves


Principal alternatives for duplication: (a) Source duplication, (b) In-network duplication, (c) Application duplication

Summary: Where to Duplicate?

Creation/transmission originating at R1

(a)

R1

R2

R3 R4

duplicate

(b)

R1

R2

R3 R4

duplicate

(c)

R1

R2

R3 R4

duplicate


Internet Multicast Service Model

Multicast group concept: use of indirection

Hosts addresses IP datagram to multicast group

Routers forward multicast datagrams to hosts that have “joined” that multicast group

128.119.40.186

128.59.16.12

128.34.108.63

128.34.108.60

multicast group

226.17.30.197


Multicast Groups

Block of class D Internet addresses reserved for multicast:

Host group semantics:

Anyone can “join” (receive) multicast group

Anyone can send to multicast group

No network-layer identification to hosts of members

Needed: infrastructure to deliver mcast-addressed datagrams to all hosts that have joined that multicast group


Multicast Group and Service Model (1)

Members of the group could be anywhere in the Internet

Members can join and leave the group and indicate this to the routers

Senders and receivers are distinct: i.e., a sender need not be amember, but receivers should be

Routers listen to all multicast addresses and use multicast routing protocols to manage groups (IGMP)



Multicast Address

IP reserved class D addresses for multicast 224.0.0.0~239.255.255.255

Base address: 224.0.0.0 is reserved

224.0.0.1~224.0.0.255 are devoted to multicast routing and groupmaintenance protocols

Multicast addresses can only be used as destination

No ICMP error messages can be generated for multicast datagram



Mapping IP Multicast to Ethernet Multicast:

Place the lower 23 bits of the IP multicast address into the lower 23 bits of special Ethernet multicast address 01.00.5E.00.00.00

32 multicast groups may be mapped into the same address. Probability is small, but receivers should check the datagram(How? → look at destination IP address)


Transmission and Delivery of Multicast Datagrams

Local subnetwork transmission

The source station simply addresses the IP packet to the multicast group

The network interface card maps the Class D address to the corresponding Ethernet multicast address, and the frame is sent

Receivers that wish to capture the frame notify their IP layer that they want to receive datagrams addressed to the group

Transmission throughout the Internet

Routers are required to implement a multicast routing protocol that permits the construction of multicast delivery trees and supports multicast data packet forwarding

In addition, each router needs to implement a group membership protocol (IGMP) that allows it to learn about the existence of group members on its directly attached subnetwork


Joining a Multicast Group: Two-step Process

Local: Host informs local mcast router of desire to join group: IGMP (Internet Group Management Protocol)

Wide area: Local router interacts with other routers to receive mcast datagram flow

Many protocols (e.g., DVMRP, MOSPF, PIM)

IGMPIGMP

IGMP

wide-areamulticast

routing


IGMP: Internet Group Management Protocol (1)

Host: sends IGMP report when application joins mcast group

IP_ADD_MEMBERSHIP socket option

Host need not explicitly “unjoin” group when leaving

Router: sends IGMP query at regular intervals

Host belonging to a multicast group must reply to query

query report



Router: Host Membership Query msg broadcast on LAN to all hosts

Host: Host Membership Report msg to indicate group membership

Randomized delay before responding

Implicit leave via no reply to Query

Group-specific Query

Leave Group msgLast host replying to Query can send explicit Leave Group msg

Router performs group-specific query to see if any hosts left in group

Introduced in RFC 2236

Current version: IGMPv3



Details of how it works:One host joins a group

Newly joined host in a group sends IGMP message to group multicast address declaring membership.Local multicast router receives the message and establishes necessary routing path

Group membership reportRouter sends Host Membership Query to 224.0.0.1 (all multicast hosts on a subnet)Host responds with Host Membership report for each group to which it belongs (sent to group address)Other hosts in the same group “suppress” reports Router periodically broadcasts query to detect if groups have gone away



Each host responds to the query with a random delay. If one report is received at the router, the other reports will be suppressed



IGMP versions

IGMP version 1: basic message formats & procedures

IGMP version2:Defines a procedure for the election of the multicast querier for each LAN

Defines a new type of Query message-the Group-Specific Query message

Defines a Leave Group message

IGMP version 3:Introduces support for Group-Source Report messages so that a host can elect to receive traffic from specific sources of a multicast group

Support for Leave Group messages first introduced in IGMP Version 2 has been enhanced to support Group-Source Leave messages. This feature allows a host to leave an entire group or to specify the specific IP address(es) of the (source, group) pair(s) that it wishes to leave

21

Multicast Routing: Problem Statement

Goal: Find a tree (or trees) connecting routers having local mcast group members

Tree: not all paths between routers used

Source-based: different tree from each sender to rcvrs

Shared-tree: same tree used by all group members

Shared tree Source-based trees

22

Approaches for Multicast Traffic Delivery

Approaches:

Flooding: no explicit forwarding topology

Source-based tree: one tree per source

Shortest path trees

Reverse path forwarding

Group-shared tree: group uses one tree

Minimal spanning (Steiner)

Core based trees

…we first look at basic approaches, then specific protocols adopting these approaches


Flooding

When a router receives a packet:Router determines whether it’s the first time it receives the packet

If so, the packet will be delivered to all interfaces except the one on which it arrived, otherwise the packet will be discarded

No routing tables needed

But: Inefficient use of bandwidth

SRCNon-red streams will be

discarded according to flooding algorithm


Towards More Efficient Multicast Delivery: Spanning Trees

Only one active path connects any two (multicast) routers

The multicast packets will not loop and reach all routers

May potentially not provide the most efficient path between the source subnetwork and group members

25

Shortest Path Tree

Multicast forwarding tree: tree of shortest path routes from source to all receivers

Dijkstra’s algorithm (→ Telematics 1)

R1

R2

R3

R4

R5

R6 R7

21

6

3 4

5

i

router with attachedgroup member

router with no attachedgroup member

link used for forwarding,i indicates order linkadded by algorithm

LEGENDS: source

26

Reverse Path Forwarding

if (mcast datagram received on incoming link on shortest path back to center)

then flood datagram onto all outgoing links

else ignore datagram

Rely on router’s knowledge of unicast shortest path from it to sender

Each router has simple forwarding behavior:

27

Reverse Path Forwarding: Example

Result is a source-specific reverse SPT

May be a bad choice with asymmetric links

R1

R2

R3

R4

R5

R6 R7



datagram will be forwarded

LEGENDS: source

datagram will not be forwarded

28

Reverse Path Forwarding: Pruning

Forwarding tree contains subtrees with no mcast group members

No need to forward datagrams down subtree

“Prune” messages sent upstream by router with no downstream group members

R1

R2

R3

R4

R5

R6 R7



prune message

LEGENDS: source

links with multicastforwarding

P

P

P


Some Improvements of the RPF Idea

Setup broadcast tree (reverse path broadcasting, RPB):

Each node maintains “parent” and “child” links

If packet from parent (“reverse-path check”) send to “children”; else drop

Consider only those links as children, for which the node is on the shortest path to the source:

With link state routing this is easy to know

Distance vector routing can make use of “poisoned reverse”mechanism to obtain this information

Truncated RPB (TRPB):

Truncate leaf if IGMP says that there are no receivers for the group.

Reverse-Path Multicasting (RPM):

Truncate branch if IGMP says that there are no receivers for the group

30

Shared-Tree: Steiner Tree

Steiner Tree:

Minimum cost tree connecting all routers with attached group members

Complexity: Steiner-Tree problem is NP-complete

Excellent heuristics exists

Allow to find approximations to the ideal solution

Good approximation: get approximation ratio as close to 1 as possible (with polynomial effort, impossible to obtain 1)

However, not used in practice for multicast routing:

Computational complexity

Information about entire network needed

Monolithic: needs to be re-run whenever a router needs to join/leave


Steiner Trees: Problem Definition

Given: Weighted graph G=(V, E, cost) and terminals S ⊆ V

Find: Minimum-cost tree T within G spanning S

b d g

a

e

c

h

f

52

5

4 1

12

3 2

3

2

3 1

2

1

b d g

a

e h1

2

1 3 1

Complexity: NP-hard [Karp, 1972]

Approximation Ratio = supOptimalCost(I)

AchievedCost(I)all instances I

32

Core Based Trees

Single delivery tree shared by all

One router identified as “center” of tree

To join:

Edge router sends unicast join-msg addressed to center router

Join-msg “processed” by intermediate routers and forwarded towards center

Join-msg either hits existing tree branch for this center, or arrives at center

Path taken by join-msg becomes new branch of tree for this router

Advantages/Disadvantages:Compared to previous algorithms, CBT can use bandwidth and router resources more efficiently

CBT may result in traffic concentration and bottlenecks near core routers since traffic from all sources traverses the same set of links as it approaches the core

A single shared tree may create trees not as optimal as source-trees

33

Core Based Trees: An Example

Suppose R6 chosen as center:

R1

R2

R3

R4

R5

R6 R7



path order in which join messages generated

LEGEND

21

3

1


Recapitulation: Pros & Cons of Different Alternatives

Cons:Reverse-Path Flooding:

Requires symmetric paths for optimal shortest path routing

Flood-and-prune:Bandwidth waste during flooding stage

Rendez-vous points (CBT):Not shortest pathsSingle-point of failure

Pros:Reverse-Path Flooding:

No loops

Flood-and-prune:Receiver wanting data does not miss any

Rendez-vous points:No flooding

35

DVMRP: Distance vector multicast routing protocol, RFC1075

Derived from Routing Information Protocol (RIP)RIP forwards the unicast packets based on the next-hop towards a destination

DVMRP constructs delivery trees based on shortest previous-hop back to the source

Flood and prune: reverse path forwarding, source-based tree

RPF tree based on DVMRP’s own routing tables constructed by communicating DVMRP routers

No assumptions about underlying unicast

Initial datagram to mcast group flooded everywhere via RPF

Routers not wanting group: send upstream prune msgs

Since version 3, RPM is used (prior versions used TRPB)

Internet Multicasting Routing: DVMRP (1)

36


Soft state: DVMRP router periodically (every 1 min.) “forgets” that branches have been pruned

Multicast data again flows down unpruned branch

Downstream router: reprune or else continue to receive data

Routers can quickly rejoin the tree

Following IGMP join at leaf

Using so-called “graft” messages

Odds and ends:

Commonly implemented in commercial routers

Mbone routing done using DVMRP

Works well in small autonomous domains

Limitations:

Distance-vector ⇒ slow to adapt to topology changes;

Must store source-specific state even when not on tree ⇒ scaling problems



If router C can receive datagrams from both A and B, then:

It will receive from A if A’s metric to the source is smaller than B’s, or

If they are equal, if A has the smaller IP address on its downstream interface

38

PIM: Protocol Independent Multicast

Not dependent on any specific underlying unicast routing algorithm (works with all)

Two different multicast distribution scenarios :

Dense:

Group members densely packed, in “close” proximity.

Bandwidth more plentiful

Sparse:

Number of networks with group members small with respect to number of interconnected networks

Group members “widely dispersed”

Bandwidth not plentiful

39

Consequences of Sparse-Dense Dichotomy

Dense

Group membership by routers assumed until routers explicitly prune

Data-driven construction of mcast tree (e.g., RPF)

Bandwidth and non-group-router processing wasteful

Sparse:

No membership until routers explicitly join

Receiver- driven construction of mcast tree (e.g., core based)

Bandwidth and non-group-router processing conservative

40

PIM- Dense Mode

Flood-and-prune RPF, similar to DVMRP but:

Underlying unicast protocol provides RPF info for incoming datagram

Less complicated (less efficient) downstream flood than DVMRP reduces reliance on underlying routing algorithm

Has protocol mechanism for router to detect it is a leaf-node router


Developed due to scaling issues

Flooding is generally a real bad idea

Based on creating routing tree for a group with Rendezvous Point(RP) as a root for the tree

RP is a focus for both senders and receivers

Explicit join model

Receivers send Join towards the RP

Sender send Register towards the RP

Supports both shared trees (default) and source trees

RPF check depends on tree type

For shared tree (between RP and receivers), uses RP address

For source tree (between RP and source), uses source address

PIM - Sparse Mode (1)

42


Core based approach

Router sends join msg to rendezvous point (RP)

Intermediate routers update state and forward join

After joining via RP, router can switch to source-specific tree

Increased performance: less concentration, shorter paths

R1

R2

R3

R4

R5

R6R7

join

join

join

all data multicastfrom rendezvouspoint

rendezvouspoint

43


Sender(s):

Unicast data to RP, which distributes down RP-rooted tree

RP can extend mcast tree upstream to source

RP can send stop msg if no attached receivers

“No one is listening!”

R1

R2

R3

R4

R5

R6R7

join

join

join

all data multicastfrom rendezvouspoint

rendezvouspoint


Only one RP is chosen for a particular groupRP statically configured or dynamically learned (Auto-RP, PIM v2 candidate RP advertisements)Data forwarded based on the source state (S, G) if it exists, otherwise use the shared state (*, G)

(*,G) means all senders

RFC2362 – “PIM Sparse Mode Protocol Spec” (experimental)Internet Draft: draft-ietf-pim-v2-sm-00.txt (October 1999)



Overview of Protocol Functions:

PIM Neighbor Discovery

PIM SM Forwarding

PIM SM Joining

PIM SM Registering

PIM SM SPT-Switchover

PIM SM Pruning

PIM SM Bootstrap

PIM SM State Maintenance



PIM Sparse Mode (6) – Tree Maintenance

Periodic Join/Prunes are sent to all PIM neighborsPeriodic Joins refresh interfaces in a PIM neighbor’s downstream listPeriodic Prunes refresh pruned state of a PIM neighbor

There is a designated router (DR) for each local network and all other routers get pruned

Received multicast packets reset (S,G) entry expiration timers.(S,G) entries are deleted if timers expire


PIM Sparse Mode (7) – Example

Receiver 1

Source

Receiver 2

S

R1

A B RP D

C E

R2



Receiver 1

Source

Receiver 2

S

R1

A B RP D

C E

R2

Receiver 1 Joins Group GC Creates (*, G) State, Sends(*, G) Join to the RP

Join



Receiver 1

Source

Receiver 2

S

R1

A B RP D

C E

R2

RP Creates (*, G) State



Receiver 1

Source

Receiver 2R1

A B RP D

C E

R2

Source Sends DataA Sends Registration to the RP

Register

Data

IP tunnel between A and RP sincemulticast tree is not established

S



Receiver 1

Source

Receiver 2R1

A B RP D

C E

R2

RP decapsulates RegistrationForwards Data Down the Shared TreeSends Joins Towards the Source

joinjoin

S



Receiver 1

Source

Receiver 2R1

A B RP D

C E

R2

RP Sends Register-Stop OnceData Arrives Natively

Register-Stop

S


Receiver 1

Source

Receiver 2R1

A B RP D

C E

R2

C Sends (S, G) Joins to Join theShortest Path Tree (SPT)

join

S


Shortest Path Tree Switchover (1)



Receiver 1

Source

Receiver 2R1

A B RP D

C E

R2

C starts receiving Data nativelyS




Receiver 1

Source

Receiver 2R1

A B RP D

C E

R2

C Sends Prunes Up the RP tree forthe Source. RP Deletes (S, G) from its outgoing interface list (OIF) andSends Prune Towards the Source

Prune

PrunePrune

S




Receiver 1

Source

Receiver 2R1

A B RP D

C E

R2

B, RP prunedS




Receiver 1

Source

Receiver 2R1

A B RP D

C E

R2

join

New receiver2 joinsE Creates State and Sends (*, G) Join

S



Receiver 1

Source

Receiver 2R1

A B RP D

C E

R2

C Adds Link Towards E to the OIFList of Both (*, G) and (S, G)Data from Source Arrives at E

S



What if source is located in remote domains?PIM-SM requires group-RP mappings to be advertised to all PIM-SM domains

Use Multicast Source Discovery Protocol, functionality is similar to BGP

Inter-domain multicast to be managed by Border Gateway Multicast Protocol (BGMP)


Multicast Routing Across AS Borders: BGMP (1)

BGMP (Border Gateway Multicast Protocol )

BGMP builds shared tree of domains for a group

So we can use a rendezvous mechanism at the domain level

Shared tree is bidirectional

Root of shared tree of domains is at root domain

Runs in routers that border a multicast routing domain

Runs over TCP

Joins and prunes travel across domains

Can build unidirectional source trees


Multicast Routing Across AS Borders: BGMP (2)

unidirectional source tree


Avoiding Multicast Address Collisions: MASC (1)

MASC (Multicast Address Set Claim )

Group prefixes are temporarily leased to domains

Allocated by ISP who in turn received them from its upstream provider

Claims for group allocation resolve collisions

Group allocations are advertised across domains

Group prefix allocations are not assigned to domains—they are leased

Applications must know that group addresses may go away

RFC 2909





Assume Addr(A) is allocated to domain A and domains B and C sit “below” A in a domain hierarchyB selects Addr(B) which is subset of Addr(A) and send claim (addr(B)) message to A and CA forwards claim to all children except B.If any of A’s children is already using Addr(B) they will report a collision to A.A will notify B of the collision and B will select other address space.Address space information is used to create distribution tree using BGMP.Stored in M-RIB (Multicast Routing Information Base)


Tunnel Encapsulation

If there are non-multicast-capable routers between two multicast routers, multicast packets are encapsulated in unicast IP packets between them:


MC-NetMC-Net

The Early Days of Internet Multicast - MBone

Sender

Receiver

UnicastRouter

MC-PacketMC-Packet MC-PacketMC-Packet

Tunnel

UC-NetUC-Net MC-NetMC-Net

MC-PacketMC-PacketUC-Head

MulticastRouter

ReceiverMulticastRouter


Inefficiencies on the MBone

UC-Router

ReceiverReceiver

UC-Router

Unicast-Network

Sender

MC-Routeron Workstation



Data Stream

Efficient multicasting requires “native” multicast support.


Why is native IP Multicast not yet available?

Multicast technology already widely deployed, but multicast service not yet turned on – why?

Multicast is hard to debug and hard to manage

There is not yet a real “killer” application.

Receivers prefer using unicast instead of the low-quality and unstable MBone service (user perception: “Multicast = MBone”)

IP multicast service model not inline with requirements for commercial deployment

No group membership control

Open to denial of service attacks

Domain dependency

Lack of a business model for multicast pricing


The IP Multicast Service Model

(Original) IP multicast offers many-to-many communication

New approaches propose a single source multicast model

Open service model, i.e. everybody can:

Create a multicast group

Receive data from a group

Send data to a group

No multicast address reservation

Problems:

Router state

Inter-domain multicast

Denial-of-service attacks


Multicast Problems: Unauthorized Receivers

Internet

Possible Solution:Data Encryption?


Multicast Problems: Denial-of-Service Attacks

Internet


Requirements for Commercial Deployment

At least same level of availability and maintainability as unicast

Easy and transparent installation:

ISP must be able to install, manage, and maintain multicast service

Setup and configuration of multicast session must have low latency and be straightforward

Group membership should be controlled

Only authorized sources send to a group

Senders want to control the receiver set

Globally unique multicast addresses

Bandwidth fairness,

Network maintenance and debugging

Appropriate business model and mechanisms for charging and billing


One Step Beyond: Reliable Multicast – The Challenge

Implement reliability on top of IP multicastDon’t necessarily care about ordering or byte-stream abstraction

Why is this hard ?Sender cannot keep state for unknown number of dynamicreceivers

Remember open & dynamic group semantic?Algorithms like TCP that estimate path properties such as RTT and congestion window don’t generalize to trees

Remember: TCP is only for a unicast session!Has to address (N)ACK implosions


R1

Example: Negative Acknowledgement Implosion

S

R3 R4

R2

21

R1

S

R3 R4

R2

Packet 1 is lost All 4 receivers request a resend

Resend request


Reliable Multicast Transport: Issues

Retransmission can make reliable multicast as inefficient as replicated unicast

(N)ACK-implosion if all destinations ack/nack at once“Crying baby”: a bad link affects entire group

Heterogeneity: receivers, links, group sizesAnonymous/Open/Dynamic Group Model:

Source does not know # of destinations, and destinations may vanish

Multicast applications do not need strong reliability of the type provided by TCP.

Can tolerate some reordering, delay, etc


Retransmission

Re-transmitterOptions: sender, other receivers

How to retransmitUnicast, multicast, scoped multicast, retransmission group, …

Problem: retransmissions (aka repairs) may reach destinations that don’t require a retransmission

A.k.a “exposure” problemSolution: subcast the re-transmission only to receivers that need it.


R1

Why Subcast? Exposure problem…

S

R3 R4

R2

21

R1

S

R3 R4

R2

Packet 1 does not reach R1;Receiver 1 requests a resend

Packet 1 resent to all 4 receivers

1

1

Resend request Resent packet


Alternative 1: Ideal Recovery Model

S

R3 R4

R2

2

1

S

R3 R4

R2

Packet 1 reaches R1 but is lost before reaching other Receivers

Only one receiver sends NACK to the nearest S or R with packet

Resend request

1 1Resent packet

Repair sent only to those that need packet

R1 R1


R1

Alternative 2: Using the Routers

S

R3 R4

R2

Routers do transport level processing:

Buffer packetsCombine ACKsSend retransmissions

Model solves implosion and exposure, but not scalableViolates end-to-end argument

NACK

RTX

Router


RMT Building Blocks: RFC 3048

NACK only: E.g. SRM uses only end-to-end mechanisms.

Tree-based ACK: aggregators reduce reverse traffic. Eg: RMTP-II

Asynchronous Layered Coding (ALC):

Use of forward-error correction (FEC), and no feedback,

Aka “proactive” FEC

Router assist:

Use of NAKs but router support for aggregation, e.g. Pragmatic General Multicast (PGM)

FEC retransmissions (aka reactive FEC) instead of data retransmissions


Ring Algorithm

ACK & NACK

Many to Many

Lowest Scalability

No Hierarchy

Multicast NACK & FEC

Simple to Implement

Moderate Scalability

Tree with Hard State

ACK & NACK & FEC

Confirmed Delivery

Requires Configuration

Ring

RMP

TRACK

RMTP-II

NACK-Only

SRM

Classes of RMT Protocols


One-level TRACK

ACK & NACK

Simple to Implement

Non Real Time

File Transfer

MFTP

Tree with Soft State

NACK & FEC

Scaleable & Auto Config

Req. New Router Code

Router-Assist

PGM

ALC (FEC)

Digital Fountain

No Return Channel

FEC Only

Highest Scalability & Supports Heterogeneity

Best for non real time or semi-reliable video

⌦ ⌫⌫

⌫

Classes of RMT Protocols


Example: Scalable Reliable Multicast (SRM)

Originally designed for a distributed whiteboard application called wb

Receiver-reliableNACK-based

Every member may multicast NACK or retransmission


R1

SRM: Request Suppression

S

R3

R2

21

R1

S

R3

R2

Packet 1 is lost; R1 requests resend to Source and Receivers

Packet 1 is resent; R2 and R3 no longer have to request a resend

1

X

XDelay varies by distance

X

Resend request Resent packet


SRM: Stochastic Suppression

datad

d

d

d

Time

NACK

repair

2d

session msg

0

1

2

3

Delay = U[0,C2] ×dS,R

= Sender

= Repairer

= Requestor


SRM: Summary

All members get all the data that has been sent to the the multicast group (packet reliability )Repair requests/responses are multicast.Scope of repair requests/responses can be TTL limited or a separate “local recovery group” can be formedTechniques to avoid implosion of repair requests, and reduce control traffic: NAK backoff timersNACK/Retransmission suppression

Delay before sendingDelay based on RTT estimationDeterministic + Stochastic components

Periodic session messagesFull reliabilityEstimation of distance matrix among members

telematics 2 - startseite tu ilmenau · pdf filenetwork multicast router actively participate...

Documents