Subject: Re: No hardware support for asynchronous streams?

From: "Wooten, David" <[email-masked]>
Date: Fri, 4 Jun 1999 15:56:04 -0500

Farrell, et al,

I don't understand Peter's second requirement for being able to work with
IPv4.  It seems to actually be saying that the nodes that one want's to talk
to can receive isochronous packets.  Isn't any node that does IPv4 required
to be able to accept an isochronous packet (that's what tcode 'A' means).
So, if a node meets case 1, isn't case 2 automagicly taken care of?  Maybe
it's simply a matter that the 1394a text says that the asynchronous stream
packet says that it has to be sent outside of the isochronous interval which
makes some people think that they should only look for an asynchronous
stream packet within the isochronous interval.  That would be, I think, a
mistaken interpretation.  Also, one might run into the same problem that we
have with isochronous packets.  The reason that some links have implemented
'loose' isochronous is because there are some corner cases when nodes don't
quite agree on whether the isochronous interval is over.  So, if it is
possible to need 'loose' isochronous support it seems to me that it seems
likely that one would need 'loose' asynchronous stream support.

David Wooten

> -----Original Message-----
> From: Farrell Ostler [mailto:[email-masked]]
> Sent: Friday, June 04, 1999 3:15 PM
> To: [email-masked]
> Subject: Re: No hardware support for asynchronous streams?
>
>
> Nagaraj,
>
> I'm pretty surprised by the claim that you can answer Peter's question
> 2 with "YES". Do you really know that all nodes with which you must
> interoperate will be tolerant of a behavior unsanctioned by
> the 1394a standard, now and into the unforeseable future?
>
> If you are talking about a node implementation that will stay within
> the controlled environment of your lab, well, then yes, you
> can know your peer nodes. On the other hand, if you are
> talking about a node implementation that will be released as an
> end-user product to the general market place, then the answer is
> almost surely NO.
>
> There *will* be link silicon that will accept tCode=A packets as
> asynchronous-stream packets only if they meet the normative
> requirement that
>
>      "An asynchronous stream packet shall be
>      transmitted during the asynchronous period ..."
>                         [P1394a Draft 2.1, Clause 8, p. 135]
>
> Hence, there will likely be nodes that implement IP over 1394
> but will not interoperate with a node having the properties that
> you describe.
>
> If you release a product with such properties, will the packaging
> or documentation carry the disclaimer, "May not interoperate
> with all devices that support IPv4 over 1394."?
>
> It is more likely that the marketing department will insist on
> something like,
>
>      "Fully compliant with the ITEF standard for IPv4
>      over IEEE Std. 1394a-1999 [aka Firewire, a trademark
>      of Apple Computer, and i.Link, a trademark of Sony]."
>
> (even though it is not completely true), piling on the acronyms
> and references to secure believability through sheer weight.
>
> The stage is then set for a scenario like this to unfold: Joe Sixpack
> buys your product, call it A, and successfully uses it for a while. He
> then purchases product B, also "fully supporting IPv4 over 1394" (and
> not even an approximation, perhaps) but finds it doesn't
> interoperate with A. He'll probably blame B, A will be at fault
> and Joe will be upset and confused.
>
> An emerging market upon which so many are counting doesn't need
> time bombs like this!
>
> For lab work, your work-around seems harmless. However, I hope you'll
> reflect seriously before releasing a node with non-compliant
> asynchronous streams behavior as a product.
>
> Sincerely,
> Farrell Ostler
> --------------------------------------------------------------
> -----------------
> Philips Semiconductors | MS55 | 9201 Pan American Fwy NE |
> Albuquerque NM 87113
> Tel: 505-822-7791 | Fax: 505-822-7836
> email: [email-masked]
> --------------------------------------------------------------
> -----------------
>
> >
> > Thanks Peter,
> >
> > I am sorry for the bad subject. I will correct myself from
> the next time.
> >
> > This reply is very useful for me. Thanks again.
> >
> > My hardware has an answer "YES" to all the questions.
> >
> > Nagaraj
> >
> > -----Original Message-----
> > From: IETF IP over 1394 Working Group
> > [mailto:[email-masked]]On Behalf Of Peter Johansson
> > Sent: Friday, June 04, 1999 8:29 PM
> > To: [email-masked]
> > Subject: No hardware support for asynchronous streams?
> >
> >
> > Before getting into the meat of my reply, I'd like to
> suggest to Mr. Nagaraj
> > that he provide meaningful subject lines to identify new
> threads. Most of us
> > get far too much EMail; a subject line such as "RE: Potential New WG
> > Charter"
> > (as this thread had before I retitled it) doesn't do much
> to identify the
> > topic under discussion. In fact, it misidentifies it!
> >
> > In a message dated 99-06-04 00:50:12 EDT,
> [email-masked] writes:
> >
> > <<Can the IP/ARP packets (in GASP format) be sent in the
> isochronous phase
> > IF
> > THE HARDWARE DOESNOT support ASYNCHRONOUS STREAM?>>
> >
> > Fisrt of all, hardware support for asynchronous stream
> packets is *really* a
> > minimum requirement for IPv4 over 1394.
> >
> > The Internet-Draft does not sanction other possibilities.
> >
> > So, your question becomes "Can I devise a functional
> work-around if my
> > hardware doesn't support asynchronous streams?"  Well, that
> depends....
> >
> > 1) Are you capable of "loose isochronous" packet reception?
> If not, stop, go
> > get new hardware.
> >
> > 2) If you did send an ARP in the isochronous period, will
> the nodes with
> > which you wish to interoperate receive it correctly? That
> is, is there
> > anything about their hardware, firmware or software
> configuration that will
> > inhibit the reception of an intended asynchronous stream
> packet if it is
> > sent
> > isochronously. Probably not, but if they can't receive it,
> stop, go get new
> > hardware.
> >
> > 3) Can your IPv4 over 1394 software stack abide by
> isochronous rules and
> > pace
> > its ARP transmissions? That is, you need to allocate
> bandwidth (since you're
> > going to transmit isochronously) and then restrict yourself
> to only one ARP
> > packet per isochronous period. If not, stop, go write new software.
> >
> > If the answer to all of these questions is "Yes," you MAY be able to
> > interoperate OK.
> >
> > Regards,
> >
> > Peter Johansson
> >
> > Congruent Software, Inc.
> > 98 Colorado Avenue
> > Berkeley, CA  94707
> >
> > (510) 527-3926
> > (510) 527-3856 FAX
> >
> > [email-masked]
> >
>

---

From: Venkat Tanikella <[email-masked]>
Date: Fri, 4 Jun 1999 15:42:49 -0700

Peter,

Even if it is a yes to all three questions I think one should not do this,
as I see
the following issues:

    - In a multi node configuration, even if each node ensures one packet
per
      isoch cycle, by way of software or hardware, since there are many
nodes
      technically multple packets using the same channel number would be
seen
      within  a single Isoch cycle, unless ofcourse there is some kind of
      understanding across the nodes.

    - Should all the IP1394 nodes allocate bandwidth or only one? if one who
      would be that? and if all is there enough bandwidth left ?

    - The bandwidth to be allocated is just not determined by ARP packets
      alone, as there could be other applications using udp broadcast, and
it is
      almost impossible to precisely guess that value unless you know all
the
      applications that are going to run before hand.

    And ofcourse if there is a neat solution it is as good as Ip1394 over
Isoch!!

-Venkat

>Thanks Peter,
....
>Before getting into the meat of my reply, I'd like to suggest to Mr.
Nagaraj
>that he provide meaningful subject lines to identify new threads. Most of
us
>(as this thread had before I retitled it) doesn't do much to identify the
>In a message dated 99-06-04 00:50:12 EDT, [email-masked] writes:
>
><<Can the IP/ARP packets (in GASP format) be sent in the isochronous phase
>IF
>Fisrt of all, hardware support for asynchronous stream packets is *really*
a
>So, your question becomes "Can I devise a functional work-around if my
>hardware doesn't support asynchronous streams?"  Well, that depends....
>
>1) Are you capable of "loose isochronous" packet reception? If not, stop,
go
>get new hardware.
>
>2) If you did send an ARP in the isochronous period, will the nodes with
>which you wish to interoperate receive it correctly? That is, is there
>anything about their hardware, firmware or software configuration that will
>inhibit the reception of an intended asynchronous stream packet if it is
>sent
>isochronously. Probably not, but if they can't receive it, stop, go get new
>hardware.
>
>3) Can your IPv4 over 1394 software stack abide by isochronous rules and
>pace
>its ARP transmissions? That is, you need to allocate bandwidth (since
you're
>going to transmit isochronously) and then restrict yourself to only one ARP

---

From: Peter Johansson <[email-masked]>
Date: Sat, 5 Jun 1999 11:52:06 EDT

Before I respond, I hope everyone understands that I'm NOT recommending the
approach contemplated by Nagaraj, just attempting to define its limitations
and potential problems.

In a message dated 99-06-04 18:44:18 EDT, [email-masked] writes:

<<In a multi node configuration, even if each node ensures one packet per
isoch cycle, by way of software or hardware, since there are many nodes
technically multple packets using the same channel number would be seen
within  a single isoch cycle, unless of course there is some kind of
understanding across the nodes.>>

This is potentially the show stopping argument. It centers around the
definition of DUPLICATE CHANNEL DETECTED, which is specifed by IEEE Std
1394-1995 clause 6.1.1.3 and P1394a clause 9.14. The latter citation is a
minor update to IEEE Std 1394-1995 clause 8.2.3.

I'm going to raise this issue on [email-masked].

If the consensus is that the stricter definition of IEEE Std 1394-1995 clause
6.1.1.3 reflects actual implementations, then the rest of this EMail thread
is moot: it is not possible to send asynchronous stream packets with
isochronous arbitration UNLESS you know you are the only node attempting to
do so during any single isochronous period. Translation: forget it!

<<Should all the IP1394 nodes allocate bandwidth or only one? if one who
would be that? and if all is there enough bandwidth left ?>>

Assuming DUPLICATE CHANNELS DETECTED is not a fatal problem, EACH isochronous
talker allocates bandwidth and then abides by that limit. Is there enough
bandwidth? Only the BANDWIDTH_AVAILABLE register knows for sure...

<<The bandwidth to be allocated is just not determined by ARP packets alone,
as there could be other applications using udp broadcast, and it is almost
impossible to precisely guess that value unless you know all the applications
that are going to run before hand.>>

No need to guess. The IPv4 over 1394 software stack that is attempting this
work-around simply has to meter ALL traffic (ARP, MCAP, broadcast, etc.) on
the channel so that no more than one such packet is transmitted in any
isochronous period.

I think this "solution" is not for the faint of heart!

Regards,

Peter Johansson

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

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

[email-masked]

<<And of course if there is a neat solution it is as good as Ip1394 over
Isoch!!>>

The Holy Grail...

Regards,