Subject: new BCM election process

From: Tom Suters <[email-masked]>
Date: Thu, 6 May 1999 14:41:59 +0200

I admit I have not been following the IP/1394 discussion but from what I
hear in this discussion I conclude that if I am watching and/or
recording a TV program on my 1394 home network using channel 31 and my
son turns on his PC (who now becomes IRM and BRM), my TV screen or my
recording goes black (or at least gives a hickup because my application
has to wait for the isoch_resource_delay of 1s before it can claim new
isoch resources).

Unless there is ALWAYS a BCM manager active on the bus, it is possible
that an application  uses channel 31. Take as an example a home network
with 61883 devicees e.g. a STB and a DVCR doing a recording and where
the PC in the study is completely switched off. The 61883 devices are
IRM capable (mandated by 61883) but not BRM capable (true for at least
the existing 61883 devices) so they might agree to use channel 31 (using
the appropriate PCR procedures).

I think this problem is real and very disturbing for a consumer and we
should find a way to prevent this from happening. Of course
re-allocation might still fail in case we connect two buses together but
I think that in the case where you just add a single BRM capable device
(the PC), everyone should stick to the rules and the re-allocation by
existing applications should not fail.

In my opinion the proposed "preemption" of channel 31 by the BRM
immediately after bus reset basically violates the isoch_res_delay
procedure of the current 1394 standard. It is also different from the
use of channel 63 as default by DVCRs. A DVCR, when it becomes the IRM
after bus reset does not automatically allocate channel 63 for itself.
It only does so if it was already using that prior to the bus reset and
according to the isoch_resource_delay procedure.

If we want to have the proposed BRM solution, we should reserve channel
31 in the 1394 standard for use by a BRM. I don't know if this would
cause problems for existing devices and applications.

Regards,

Tom Suters
--
+===========================================
| Tom Suters
| Philips Research Laboratories,
| Building WLp-3.15, Post Box WL01
| Prof. Holstlaan 4
| NL-5656 AA EINDHOVEN
| The Netherlands
|
| tel:  +31-40-2744233/2744696
| fax:  +31-40-2743741
| E-mail: [email-masked]
|               [email-masked]
+===========================================+

---

From: "Hattig, Myron" <[email-masked]>
Date: Thu, 6 May 1999 12:07:43 -0700

Peter,

Is there a problem with using the new BCM algorithm but with a dynamically
allocated channel number? This solution removes the need to hard code the
channel number to 31. By not hard coding the channel to 31, we relieve
Kenji/Tom's concerns that some other device may have or get channel 31.
Also, I think dynamic allocation increases the probability of proper
operation in implementations where the BCM and IRM are implemented within
different modules.

-myron

---

From: "Hattig, Myron" <[email-masked]>
Date: Fri, 7 May 1999 21:51:19 -0700

Okay, sounds like the only objections to the new process are the fact
that it requires a fixed channel number. A fixed channel number bothers
at least one CE vendor, breaks a leading 1394 stack, but may fix a bridging
problem related to maintain clock cycles.  Frankly, this is outside the
scope of the IP/1394 WG. I suggest bridging folks get support the leading
CE and PC vendors and comprehensive review of the lastest p1394.a draft
wrt the fixed channel number then get back to IP/1394 WG. Until then,
I suggest implementations simply use the BCM election process that was
formally called the NPM election process in earlier IP/1394 drafts. Note,
draft version 15 is not affected by this issue if we use the NPM election
process previously defined in the IP/1394 WG.

-myron

> -----Original Message-----
> From: Peter Johansson [mailto:[email-masked]]
> Sent: Friday, May 07, 1999 10:59 AM
> To: [email-masked]
> Subject: Re: new BCM election process
>
>
> In a message dated 99-05-06 15:08:05 EDT,
> [email-masked] writes:
>
> <<Is there a problem with using the new BCM algorithm but
> with a dynamically
> Kenji/Tom's concerns that some other device may have or get
> channel 31. Also,
> I think dynamic allocation increases the probability of
> proper operation in
> implementations where the BCM and IRM are implemented within different
> modules.>>
>
> Yes, there is a difficulty with a dynamically allocated
> channel number.
>
> The most critical consideration is not the allocation of some
> channel (any
> channel) to serve as a generic (and default) broadcast channel for the
> bus---although this is incredibly useful. The killer argument
> is the P1394.1
> need for a way to adjust the frequency of the cycle master on
> each bus in a
> net of bridged buses.
>
> There is ongoing controversy in P1394.1 as to whether or not
> maitaining
> frequency lock across bridges is SUFFICIENT (some are
> advocating a net-wide
> system time and the ability to select the one "best" clock
> source for house
> synchronization) but all of the participants in the
> discussion agree that
> frquency lock is NECESSARY.
>
> We examined a lot of approaches to cycle clock adjustment in
> P1394.1 and in
> the end concluded that only one was workable: a "go fast/go
> slow" packet
> transmitted with isochronous arbitration. OK, one asks, "On
> what channel?" It
> was at this juncture that we realized we needed to
> consolidate our needs with
> related needs from the BCM.
>
> It is important for the clock adjusting node (we expect it to
> be a bridge
> portal) to be able to RAPIDLY resume transmission of
> adjustment packets after
> a bus reset if cross-bridge isochronous traffic is not to be
> disrupted. It is
> not feasible to wait for dynamic allocation of a channel.
> Hence the need for
> what is, in essence, a hard-wired well-known channel number.
>
> But the cow is out of the barn with respect to demanding such
> a channel
> number in a standard. We have to get it by guile, by making
> the BCM the
> IRM---the only node that can guarantee the allocation of a
> particular channel
> number.
>
> In a later EMail Kenji poses the following objection to
> placing the BCM
> functionality at a level where it may GUARANTEE the
> availability of channel
> 31:
>
> <<I think it can not be accepted in the real world.>>
>
> In actual fact, I think it's ESSENTIAL that it be accepted in
> the real world
> because it's not at all clear that we have viable alternatives.
>
> At one point in this thread it was suggested that P1394a
> forbid any node
> except the BCM from attempting to allocate channel 31. That
> might be useful,
> but it is only a partial solution. It is only by making the
> BCM the IRM that
> we can enforce the availability of channel 31. And as this
> feature comes to
> be implemented, Tom's concerns that a newly arrived BCM
> preempts preexisting
> programming channel 31 fade into the distance.
>
> One of the challenges of working with any emergint technology
> is that we do
> not always get things "right" the first time. This is
> practically a given. I
> think that the BCM solution that utilizes channel 31 is NOT an ad hoc
> solution to a narrow problem but a generic attempt to solve a
> serious problem
> with the LEAST disruption---not necessarily NO disruption (as
> we didn't have
> a crystal ball).
>
> Regards,
>
> Peter Johansson
>
> Congruent Software, Inc.
> 98 Colorado Avenue
> Berkeley, CA  94707
>
> (510) 527-3926
> (510) 527-3856 FAX
>
> [email-masked]
>

---

From: "Wooten, David" <[email-masked]>
Date: Sat, 8 May 1999 09:50:27 -0500

Myron,

I sympathize with your intent to close your spec while letting other
committees solve their problems.  However, it may be that this is another
case that is like asynchronous streams that needs cooperation among all the
committees in order to make it fit together.

A concern that the 1394.1 folks have is that they will be asked to carry
asynchronous packets across buses that may not have any node with a lot of
bus management smarts.  The prototypical case is star wiring in the house
where there are bridges at the walls in each room and the single 1394b bus
behind the wall is connected to a central wiring closet where the patch
panel is.  There may be nothing but bridge portal devices on that bus behind
the wall.  When bridges are designed, the designer doesn't know whether the
bridge is going to be on a bus with nothing but portals or on a bus with
other 1394 devices.  As a consequence, they have to use the same management
algorithms that everyone else uses.  The implication of this and a choice to
leave the BCM algorithm alone, is that every portal will have to be designed
to be a BCM.  Otherwise, there will be no NPM on the bus behind the wall, no
broadcast channel will be assigned, and no IP will get through the home
network.  So, simply stating that the algorithm should be left alone has a
cost impact on a lot of other folks.

I think everyone who is working on 1394 related standards needs to be
cognizant of the work going on in there groups.  We can't throw our hands up
in disgust when the work of 'another' group or groups seems to be impeding
the progress in 'our' spec.  Fact is, all these individual specs are part of
a larger fabric that we call 1394.  We have to get the threads to mesh or
else we will have a pile of lint instead of a wonderful tapestry (my, but I
feel so poetic today).

Anyway, bad analogies aside, this is important stuff and we have to work
through these annoying problems that are created by 'other' groups.  In your
list of laments, I didn't see anything that was insurmountable.  We need to
talk to the one CE vendor who had an issue.  It might be that he was simply
stating a preference rather than a law.  After all, the CE folks have more
or lest 'pre-allocated' channel 63.  Why can't someone else pre-allocate
another channel (BTW, there is no way in hell that a single 1394 bus can
possible support 63 simultaneously active, isochronous channels so we can
afford to give up a few to worthy causes.)  I don't know why a fixed number
breaks a leading stack.  It may be that we end up with some isochronous and
non-isochronous traffic on the same channel for a period of time, but we
might be able to sort that out with tags (don't like to have to do this but
it works).

In summary, as much as I know you would like to close this and move on, I
don't think you can.  You might be right that the assignment of a fixed
channel number is outside of the scope of this group, but that doesn't mean
that it should be dismissed.  It means that the problems of getting a fixed
channel number for asynchronous broadcast has to be worked in a different
venue and then this group can count on it.  There are people who are willing
to work this if you aren't.  Don't make it impossible for them to achieve a
positive result.

David Wooten

> From: Hattig, Myron [mailto:[email-masked]]
> Sent: Friday, May 07, 1999 11:51 PM

---

From: "Hattig, Myron" <[email-masked]>
Date: Sun, 9 May 1999 22:16:56 -0700

David,

Please understand my points.

I have some private interoperability testing coming up in the near future.
I would like that testing to use the previously defined NPM election
process.
Until we agree otherwise, any WG interoperability testing should plan to use
the previously defined NPM election process. The sole purpose of this is so
that
implementations interoperate.

Implementations need to use old NPM election process because, IMHO, the
BCM election process in the p1394.a spec is not stable. My opinion is based
on
the postings on the IP/1394 mail list; specifically postings from two major
1394
CE vendors (Sony & Philips) that I thought were closely tied into the latest

happenings of p1394a. I don't know what the process is to settle the p1394.a

spec, thus I have no way of knowing how long it will take for the p1394.a
spec
to settle. Once the p1394.a spec settles, then all IP/1394 WG
interoperability
testing will use whatever BCM election process is stated in the p1394.a
spec.
Any other BCM election process would be in error.

The most relevant point: there is no reason for the IP/1394 spec to be
stalled due to
a changing BCM election process. That is, the p1394.a BCM election process
does not
affect the TEXT in IP/1394 spec. IP/1394 TEXT only relies on the existence
of a
broadcast channel (see other mail sent by Peter).

I have a strong interest in finding the best solution, fixed channel or
dynamically
allocated channel. I know the IP/1394 list is NOT the place to resolve this
issue
because there are not enough of the core 1394 folks active on this list.
Like Kenji,
I would like learn how to participate in the BCM discussion.

Now ... I hope you no longer think I'm not willing to work on this or that
I'm making it
impossible for anyone to achieve a positive result.

-myron

---

From: Peter Johansson <[email-masked]>
Date: Mon, 10 May 1999 23:40:08 EDT

In a message dated 99-05-10 01:17:11 EDT, [email-masked] writes:

<<Until we agree otherwise, any WG interoperability testing should plan to
use the previously defined NPM election process. The sole purpose of this is
so that implementations interoperate.>>

Pragmatically, it is important that BCM implementations swtich to the new
methodology soon. We cannot leave this out of interoperability considerations!

My reasons for raising an alert about the BCM NOW are to quickly build
consensus to switch to the only mechanism found to be viable for P1394.1.

If we fail to grapple with this problem, we may well create larger (perhaps
insoluble) problems for ourselves in the future.

<<Implementations need to use old NPM election process because, IMHO, the BCM
election process in the p1394.a spec is not stable. My opinion is based on
the postings on the IP/1394 mail list; specifically postings from two major
1394 CE vendors (Sony & Philips) that I thought were closely tied into the
latest  happenings of p1394a. I don't know what the process is to settle the
p1394.a  spec, thus I have no way of knowing how long it will take for the
p1394.a spec to settle. Once the p1394.a spec settles, then all IP/1394 WG
interoperability testing will use whatever BCM election process is stated in
the p1394.a spec. Any other BCM election process would be in error.>>

Define "settle" in the context of P1394a.

***** Is it when a revised draft is prepared for IEEE recirculation ballot? A
"final release candidate" of this draft should be available on the P1394a FTP
site by the end of May (although the final BRC meeting is not scheduled until
the end of June).

***** Is it when the IEEE has initiated the recirculation ballot? This timing
is out of our control, so let's guess they can get it started in either July
or August.

***** Is it when the ballot concludes and all of the ballot materials are
forwarded to the Chair? IEEE control, again; let's guess October or November.

*****Is it when a BRC is convened and pubishes a candidate standard that
differs only editorially from the draft balloted a second time?

*****Is it when the IEEE approves the document as a standard, sometime in
2000?

*****Or are there technical ballot comments unrelated to the BCM that
necessitate a third ballot?

We need to establish consensus, NOW, within the community of "early
adopters." However much one might wish to disentangle the destiny of IP/1394
from P1394a, it's not practical and cannot be deferred.

<<The most relevant point: there is no reason for the IP/1394 spec to be
stalled due to a changing BCM election process. That is, the p1394.a BCM
election process does not affect the TEXT in IP/1394 spec. IP/1394 TEXT only
relies on the existence of a broadcast channel (see other mail sent by
Peter).>>

ABSOLUTELY AGREE, the IP1394 IPv4 specification can move forward
independently. What needs to be confronted now is what our implementations do.

<<I have a strong interest in finding the best solution, fixed channel or
dynamically allocated channel. I know the IP/1394 list is NOT the place to
resolve this issue because there are not enough of the core 1394 folks active
on this list. Like Kenji, I would like learn how to participate in the BCM
discussion.>>

I disagree. Outside of P1394.1, the IP1394 reflector is the ONLY place to
have this discussion---if the implementors here can agree on a modified BCM
it will figure strongly in any p1394a ballot resolution.

Regards,

Peter Johansson

Congruent Software, Inc.
98 Colorado Avenue
Berkeley, CA  94707

(510) 527-3926
(510) 527-3856 FAX

[email-masked]

---

From: "Hattig, Myron" <[email-masked]>
Date: Tue, 18 May 1999 17:30:52 -0700

Peter,

I'd like to explore the dynamically allocated channel a little more ...

I won't pretend to understand the clocking issues, but it sounds like
you wish continue using a channel immediately after a bus reset. This
is allowable for 1 second after a bus reset under standard 1394 rules.
Is there a need to continue using the same channel after the 1 second
of the bus reset? Are bridging folks worried about losing a small
number of clock packets or an entire seconds worth of clock packets?

-myron