Subject: ttl problems ?

From: [email-masked] (Kyungran Kang)
Date: Mon, 14 Oct 1996 16:19:29 -0900 (GMT)

Hello.

Host group membership is controlled by ttl of
IP multicast packet. TTL mechanism has a problematic
aspects.

Let's assume that a host group determins the ttl
of their packets as t. If two hosts are t hops from the
group creator, they can 2t hops from each other(if 
they are on the opposite side from the creator).
In that case, they can't see each other by the 
definition of ttl. The multicast packets are not
delivered between them.
In case of broadcasting, it is not so much problem, 
but in case of conferencing, it is a problem. 
Participants can't see all the participants of the
session.

What do you think about my scenario?
How do you think we can solve this problems?

I'd like to listen your ideas. 
Thanks in advance.
Sincerely,

Kyungran Kang

---

From: Mark Handley <[email-masked]>
Date: Mon, 14 Oct 1996 09:59:04 +0100

>definition of ttl. The multicast packets are not

Yes, your scenario is the case.  TTL scoping (except for expanding
ring searches, etc) is something of a hack.

In the mbone, high TTL thresholds are set on some tunnels to create
borders.  If a packet arrives at such a border with TTL < threshold,
the border mrouter doesn't forward it.  

The borders to Europe have ttl 64 threshold - if I send with a TTL of
63, I know the TTL won't decrement to zero before reaching the other
side of Europe, and I know my traffic won't leave Europe.  Similarly,
we use TTL 16 as the threshold out of University College London, and
48 as the threshold out of the UK.

But we're also starting to scope traffic based on multicast address
range too, and this is a more powerful technique because it allows
more subtle configurations to exist.

Hope this helps,

Mark

---

From: Jonathan Day <[email-masked]>
Date: Mon, 14 Oct 1996 10:33:28 +0100 (BST)

> more subtle configurations to exist.

Is there any means of user-defining the scope, either at present or
planned? For example, if I were to set up a multicast session to
connect to people in England and Australia, I'd be eating up bandwidth
in the US and most of Europe quite unnecessarily. Likewise, it must be
that every time someone creates a multicast session aimed at specific
groups (look at how many sessions are encrypted!), where those groups
are on the opposite side of the boundaries, that traffic is going to
wind up on this local area net, even when there's no-one here who wants
to receive it.

What I'd ideally like is some way of telling routers to copy as needed,
rather than 'all or nothing'.

Jonathan

---

From: Graeme Wood <[email-masked]>
Date: Mon, 14 Oct 1996 10:48:14 +0100 (BST)

> planned? For example, if I were to set up a multicast session to

As Mark Handley has already said there is a method of providing scope
using administrative boundaries on the routers which prevents forwarding
of packets which use particular multicast group addresses.

> wind up on this local area net, even when there's no-one here who wants

This is not the case. You are forgetting that most (I hope) of the Mbone
employs some form of pruning which prevents the whole world from being
flooded by everyone's multicast.  It is true that when a sender starts
sending it will flood the network but if there are no receivers interested
on a LAN then that traffic will get pruned back.

> rather than 'all or nothing'.

It is a long time since the 'all or nothing' approach has been used,
though there are still a number of non-pruning multicast routers out there
in the world (luckily not in the UK).

=============================================================================
Graeme Wood                                 Email: [email-masked]
Unix Systems Support                        Phone: +44 131 650 5003
The University of Edinburgh                 Fax:   +44 131 650 6552
-----------------------------------------------------------------------------
Scottish MICE National Support Centre       Email: [email-masked]
for your multimedia conferencing support    WWW:   http://mice.ed.ac.uk/mice/
=============================================================================

---

From: Mark Handley <[email-masked]>
Date: Mon, 14 Oct 1996 11:24:33 +0100

>wind up on this local area net, even when there's no-one here who wants

If pruning was deployed everywhere (and it should be soon), the
traffic would prune back rapidly to only those route that require it.

At least in theory - in practice, ttl scoping means that TTL
boundaries (which your traffic reaches but does not exceed the
threshold) do not prune because they can't tell whether some higher
TTL traffic may come along later which should be forwarded.  With
admin scoping, a border router can prune back scoped groups.

>rather than 'all or nothing'.

Perhaps what you're thinking of is sparse-mode algorithms like CBT or
Sparse-mode PIM.

See the following drafts for more details:
  draft-ietf-idmr-pim-sm-spec-08.txt,.ps
  draft-ietf-idmr-pim-arch-02.txt,.ps
  draft-ietf-idmr-cbt-spec-06.txt

Mark