[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SUBTREE_MCAST ?!
Chris,
Coincidentally, we're working specifically on local recovery
mechanisms that use subtree multicast (which we call "subcasts").
Eshwar Belani ([email protected]) and Adam Costello
([email protected]) did some great work for a class project
this past semester --- I believe they each implemented some form
of subcast within ns. However, I don't think their extensions
have yet been integrateed into the master release. If you're
interested, you might contact one of them for their current status.
> Anybody heard of this feature yet? Is there any router who supports this
> feature? Is there any support in ns-2 for that?
I don't believe anyone has actually deployed a subcast forwarding
service in a real network. We've worked out (a preliminary)
implementation plan that requires only a small set of changes
to the reference IP multicast forwarding path. So it should be
relatively straightforward to implement and deploy on an experimental
basis. We hope to do this sooner rather than later, but aren't actively
engaged in the task just yet...
Attached is a note I sent to the rm list a while back for reference.
Steve
> Hello everybody,
>
> does anyone know if there is support in current internet routers that would
> make it possible for hosts ("designated receivers" within a multicast
> hierarchy) to instruct a router to send a particular packet along the
> multicast-tree that is rooted at the SENDER (rather than at the designated
> receiver)?
>
> For multicast-retransmission within a local group, I think this is a
> required feature when a particular receiver is supposed to act as a
> substitute for the sender. The designated receiver would then send the
> repair packet to some nearby router in the multicast-tree and instruct him
> to forward it along the that tree, so that it gets flooded in the very same
> way as it would if it was sent by the multicast sender itself. The authors
> of RMTP say/predict that there is/will be a new IP service (such as those
> listed in /etc/services) called SUBTREE_MCAST that is essentially
> IP-encapsulation with advise for the router to insert a fake source
> address.
>
> Anybody heard of this feature yet? Is there any router who supports this
> feature? Is there any support in ns-2 for that?
>
> Thanks,
>
> Chris.
>
------- Forwarded Message
Date: Mon, 14 Apr 1997 08:35:34 -0700
From: [email protected]
Subject: Re: Router forwarding services for reliable multicast
To: Jon Crowcroft <[email protected]>
Cc: [email protected], [email protected],
[email protected],
[email protected],
[email protected] (Adam M. Costello)
Jon,
> anyhow, very neat idea....and i think your minimal router state is
> okish, but is not quite minimal enough (for me!)
I agree with you that Christos' approach has redeeming qualities
but that this minimalist approach is not quite minimal enough.
We've been looking at this problem in a similar light: what is the
minimal amount of function that we might introduce into the network
to facilitate local recovery for reliable multicast (in addition
to improving and/or enabling a number of other unrelated end-to-end
protocol issues)? The tack we've taken is to experiment with
precisely the directed multicast concept being discussed in this
thread. Adam Costello has been designing one such scheme for a
class project here and he's coined this mechanism "subcast" after
the "subtree multicast" primitive described in the RMTP paper.
I believe both Christos' and the RMTP approaches (as well as
your strawman upstream-/downstream-only bit) involve
more mechanism than is necessary. Our mechanism (which I must
confess hasn't yet been implemented or thought through in comprehensive
detail) uses a simple variant of ip-in-ip encapsulation: A subcast
is sent with respect to a source S (or a core or an RP) at
a distance L. The outer IP header is addressed to S (from receiver R)
and the inner header is addressed to group G from S (or perhaps the
router). An application-level header could explicitly list R if needed.
The TTL in the outer header is set to L. When the TTL reaches 0,
a subcast-capable router will decapsulate the packet and forward it
as normal (i.e., send the subcast down the subtree rooted at that
router with respect to S). Now this violates the semantics of the
TTL, but we could introduce a new ip protocol type that was exactly
the same as ip proto 4 but allowed the packet to be decapsulated
when the TTL reaches 0 (which still violates the TTL semantics
but introduces no "surprises"). Alternatively, if the end-system
knows the address of the router (because it discovered it using our
subcast mechanism), it could simply tunnel the packet to the
router directly.
Note that this change is really quite minimal. It builds only on
existing mechanism --- ip-in-ip encapsulation and time-to-live.
Our subcast scheme is completely backward compatible
because IP routers will forward all packets as normal,
and new end-to-end protocols can leverage subcasts in an incremental
fashion by dynamically detecting if routers at certain distances
are subcast-capable (i.e., by sending subcasts and noting
if they do or do not come back).
One caveat is that the unicast routing protocols must align
with the multicast protocols in order for this to work.
You can probably imagine some reasonable workarounds for
this problem, but note that if we design protocols
that assume subcast-capable routers are not a requisite
but just an optimization (i.e., for incremental deployment),
then we can treat the multicast/unicast routing mismatch
simply as the absence of a subcast router.
> 3. for dynamics: have a dynamic set of groups which are joined by
> people on shared loss subtrees - look at loss distribution functions
> ...
Sure. This is the hard part...
One last thing. From Markus:
> The core problem you are talking about is how to define 'distance' in the
> sense of defining Local Groups. You have both been talking about delay
> and number of hops. What about other metrics? ...
I don't agree with this. Correlated loss in a multicast distribution
is exactly a function of the underlying routing tree and subcasts give
the optimally constraining reach to the affected area. The use of any
other distance metric for local group formation (i.e., other than hop count
to subcast root) would be suboptimal. Does this make sense?
Steve
------- End of Forwarded Message