Subject: No hardware support for asynchronous streams?

From: Peter Johansson <[email-masked]>
Date: Fri, 4 Jun 1999 10:59:25 EDT

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: Nagaraj G <[email-masked]>
Date: Fri, 4 Jun 1999 21:01:25 +0530

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?

get far too much EMail; a subject line such as "RE: Potential New WG
Charter"

<<Can the IP/ARP packets (in GASP format) be sent in the isochronous phase
IF
THE HARDWARE DOESNOT support ASYNCHRONOUS STREAM?>>

inhibit the reception of an intended asynchronous stream packet if it is
sent

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.

Regards,

Peter Johansson

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

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

[email-masked]

---

From: Farrell Ostler <[email-masked]>
Date: Fri, 4 Jun 1999 14:15:26 -0600

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]
-------------------------------------------------------------------------------