Subject: Re: Changes since draft 15

From: "Hattig, Myron" <[email-masked]>
Date: Fri, 17 Sep 1999 15:12:21 -0700

> I'm confused. I thought ownership transfer didn't result in a channel
> change. Just the owner changes.

There are two cases during transfer. In one case it does not change.
In the second it does change. It change occurs when the advertisements
of less than 30 seconds are lost by nodes wanting to become the owner,
then the current owner starts advertising with expire time of 0, the
old channel is deallocate, then all senders allocate and contend for
a new channel. This is the text Peter just added.

> > In the case of the initial transmission of ip mcast, the delay may
> > help the loss of packets, but does this matter?
>
> I'd say yes. Go back and reread Grenville's message. Although packet
> loss can occur, and higher-layer protocols need to deal with such
> cases, a spec should not knowingly allow packets to be lost when there
> a simple and low-cost fixes. There is almost always a performance
> penalty when the apps have to deal with packet loss.  In the case
> where a channel change is taking place (from default to a specific
> one) just having the channel owner (and everyone else) delay for 100
> ms (I'm not sure what the right value would be, but it could short)
> before sending would clearly avoid some types of loss. As to whether
> that matters, that depends on the application. Not wise to make
> predictions here, especially since we don't know what future
> applications will be like.

I understood what he said and in theory agree with Grenville's comment.
How to temper that theory with reality requires a perspective from the
app level. On one hand I can see how lost packets will negatively
affect apps. Also I can see delaying the start time from the advertise-
ment may negatively affect apps if the receiver starts before
the packets can be received. I'm not an expert, but it seems some
ip mcast apps require "priming-of-the-pump", if there is no data to
prime the pump, what does the app do? Does it wait indefinitely or say
"no data available, try again later"???? If we were talking about
1 or 2 seconds worth of packets, I could clearly see the benefits,
but were talking about less than a second (if advertisements are
not lost).

> Thinking about it, there are  similar (but worse) problems when
> overlapped channels occur. Would it make sense to have a delay timer
> that is slightly longer than it takes for the overlapped channel
> condition to be detected and corrected

Hmm... it seems a delay would be the most useful in the overlapped
case, because it prevents senders that lost contention from sending
packets that no app will ever receive.

> > Typically it takes several seconds to start an IP mcast stream to
> > buffer and sync data so will the lost packet be noticed?
>
> You are making assumptions that I don't think it is wise to make.

One of the biggest problems is determining the correct delay time.
Suggestions on how to figure this out?

Also, I'd like to hear about the potential negative side of such a timer.

-myron

---

From: Thomas Narten <[email-masked]>
Date: Mon, 20 Sep 1999 16:23:51 -0400

> the packets can be received.

Why? The receiver doesn't *stop* listening to the default channel (the
case I'm assuming is the common one) when switching to another
channel, so any traffic sent on the default channel will still be
received.

> I'm not an expert, but it seems some ip mcast apps require
> "priming-of-the-pump", if there is no data to prime the pump, what
> does the app do? Does it wait indefinitely or say "no data
> available, try again later"???? If we were talking about 1 or 2
> seconds worth of packets, I could clearly see the benefits, but were
> talking about less than a second (if advertisements are not lost).

You are making assumptions about the way things work... I guess I am
too, but mine are different... :-)

Here is an alternate scenario. It is not applications, but the device
driver that decides when to allocate a separate channel. The
application starts sending, the driver monitors traffic for a while,
then decides its worth allocating a separate channel (without the
application even being aware of this). At this point, packets getting
transmitted during the channel switch that get lost *might* negatively
impact the application.  This problem could be completely avoided,
however, if the sender delayed an amount of time sufficient to allow
all potential recievers to set up the receive channel.

Another example is a router doing this, where the multicast stream is
coming from the internet (indeed, how else would you do it?).

This common case (switching from a default channel to an allocated
one) seems like a common case where one wants to avoid packet losses
if feasible.

> packets that no app will ever receive.

I actually think the earlier case described above is the more
important one to deal with, as it could be common. For the overlapped
case, it might be useful to wait until the protocol goes to draft and
there is implementation experience saying its needed. Indeed, when
does the overlapped case even occur? You have to have at least two
senders decide simultaneously that they want to allocate a
channel. That rules out an entire clase of applications already.

It might also be fixable by having a simple rule like "if a
transmitter detects an overlapped channel, it MUST use the default
channel for a period of XXX seconds to allow the contention to be
resolved." This should take place in ten seconds max, right?

Again, this might be something to deal with later, if (for example),
folks decide that it would be good to include some rules that suggest
when a separate channel should be allocated. Right now, there are no
recommendations in this area at all, I believe.

> Suggestions on how to figure this out?

I'd guess something like 100 ms would be more than enough. Consider a
implementation that does MCAP processing as a process using raw
sockets. You'd want them to be able to work OK.

> Also, I'd like to hear about the potential negative side of such a timer.

Well, you'd be using the default channel for a bit longer than
before. The available bandwidth may be less than on the other channel
(right)?. But if we're talking 100ms, thats a short enough time that
it may not matter.

Thomas