Subject: IP over 1394 isoc useful?

From: "Hattig, Myron" <[email-masked]>
Date: Fri, 4 Jun 1999 08:18:31 -0700

I sent this a few days ago but it has not arrived in my mailbox yet, so
I'm resending .... Here's the msg:

In a private note Phillipe asked why people are not interested in IP over
1394 isoch. I'm posting my answer to him to the IP/1394 reflector because
others may be interested.

The Internet cannot support isoch traffic. I don't know this for sure, but
I speculate that this single aspect causes most people to lose interest in
IP
over 1394 isoch. Many people think 1394 async streams will do the job just
fine with higher layers managing bandwidth like on other links.

If the Internet cannot support isoch traffic, we are left with only
considering
isoch traffic that spans the home network. The only apps I know of that
need the bandwidth and isochrony provided by 1394 isoch streams are
entertainment video (e.g. broadcast TV, satellite TV, VCR, DVD, HDTV).
All these apps require high 3-19 Mbps isoch streams. There are two problems
here.

The first problem is with the other link layers in the home. If 1394.b is
installed to all devices in the home, there is no link layer problem, but it
is
very unlikely all devices will be connected via 1394.b. In fact, it is very
unlikely that multiple 1394 clusters (when they exist 5 years from now) will
be connected via 1394.b. Instead people are more likely to purchase a second
VCR, DVD player, etc. than to poke holes in walls and install the new media
required for 1394.b. The only other home networking link layer that supports
the bandwidth necessary to carry video streams is fast Ethernet. Fast
Ethernet also requires poking holes in walls. Other home network link layers
over phone line, radio frequencies, and powelines - that don't require
poking
holes in walls - cannot support the bandwidths required to carry high
bandwidth isoch streams.

The second problem relates to competing solutions. Lets assume someone pokes

holes in the walls to install a 1394.b network; this means video will only
traverse
1394 links.  If video streams stays on just 1394 links, an alternative,
existing
solution is better than video over IP over 1394 isoch. The solution is video
over
IEC 61883 CIP  over 1394 isoch. CIP is not routable like IP but does not
waste
20% of the bandwidth like IP. Specifically, video is carried over RTP over
UDP
over IP over 1394. RTP/UDP/IP headers consume 40 bytes, this is about 20%
of a 188 byte MPEG2 packet. The IEC 61883 headers get the job done and only
consume a few bytes.

It will be extremely useful to setup the video stream (e.g. PLAY command of
VCR)
using IP packets because IP is routeable from any other link layer in the
home
(e.g. wireless handheld pad),  but I don't see how IP over 1394 isoch can be

useful. BTW, I'd be extremely happy to be wrong about IP over 1394 isoch
because at emotional level it seems like IP over 1394 isoch should be
defined;
I just don't know of logical reasons to do it.

-myron

---

From: "Allison, Art" <[email-masked]>
Date: Wed, 9 Jun 1999 09:10:18 -0400

See EIA 775 for the U.S./Canada vol. industry standard way to set up a MPEG2
TS Isoc channel or a MPEG2 program stream over 1394 (also documented in
SCTE's DVS 194 and 195; with 194 containing 5C copy protection as well). The
EIA doc is available from Global Engineering Documents, the DVS docs from
SCTE via their web page.
Art
::{)
-----Original Message-----
From: Peter Johansson [mailto:[email-masked]]
Sent: Tuesday, June 08, 1999 7:13 PM
To: [email-masked]
Subject: Re: IP over 1394 isoc useful?

In a message dated 99-06-07 12:03:35 EDT, [email-masked]
writes:

<<What I want to do for now is to send "video over IP" stresm on 1394. We
have an AV server on 1394, and the 1394 has the ability of iso transmission.
So I want to have a mechanism to bind IP and iso 1394.>>

Why not work on a standard, interoperable method of control via IP and
separate isochronous data streams in a 61883 format? If the scope of the
problem is within the home, perhaps we define the problem too large if we
think we need isochronous IP.

Regards,

Peter Johansson

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

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

[email-masked]

---

From: Myron Hattig <[email-masked]>
Date: Wed, 9 Jun 1999 08:01:56 -0800

ÀÌÈñÁø wrote:
>
> Peter Johansson wrote:
> >
> > In a message dated 99-06-07 12:03:35 EDT, [email-masked] writes:
> >
> Well, This means we need new 1394 friendly applications, right?
> It is clear that we need new applications for new types of service, but
> there are a lot of PC based applications reusable. so does the
> programmers' skill. Without variety of applications, maybe a transfer
> method hardly succeed even if it's good.(ATM can be one of them, maybe.)
> Thus, personally I think, "a mechanism to bind IP and iso 1394" is
> useful for the PC applications.

What PC applications are folks thinking of? Do you mean programing
interfaces/environments? If so, do you mean Winsock2? Direct Show? Home
API? the API for HAVI?

Of these, only Winsock2 is tightly bound to TCP/IP, but someone could
easily write a Winsock2 Service Provider that supported IEC 61883. At
last year's CES, I thought Sony showed Direct Show IEC 61883 Filters on
their slim (e.g. 505) 1394 laptops.

So back to the original question: what PC applications, APIs, or
environments are you referring to?

-myron

---

From: "Allison, Art" <[email-masked]>
Date: Wed, 9 Jun 1999 12:21:59 -0400

1. The Consumer Electronics and Cable standards for the US require S200.
2. I have been told by many manufacturers that the complexity(cost)
differential between S100 and S200 is so small that S100 is unlikely to
often be seen.
3.  a tad <64 Mbps  <smile>
Art
::{)

-----Original Message-----
From: Myron Hattig [mailto:[email-masked]]
Sent: Wednesday, June 09, 1999 12:11 PM
To: [email-masked]
Subject: Re: IP over 1394 isoc useful?

Ken,

Good response. One more comment about 1394.b. One version of
1394.b operates at 100 Mbps overall bandwidth leaving only 80
Mbps for isoch data. If we use 20% of that 80 Mbps, we are
left with 64 Mbps. This is still quite a bit of bandwidth,
but not as large as most people assume with 1394.

-myron

---

From: "Hattig, Myron" <[email-masked]>
Date: Wed, 9 Jun 1999 09:32:59 -0700

I agree about S100 vs S200 when using 1394-1995 cables. I was referring to
the new new media types (CAT 5 UTP, POF) from p1394.b. These new media types
use a completely different phy layer with 8b10b encoding which is completely
different than 1394-1995.

-myron

> From: Allison, Art [mailto:[email-masked]]
> Sent: Wednesday, June 09, 1999 9:22 AM
> To: [email-masked]'; [email-masked]
> Subject: RE: IP over 1394 isoc useful?
>
>
>

---

From: "Allison, Art" <[email-masked]>
Date: Wed, 9 Jun 1999 12:52:07 -0400

Ahh. Thanks. Sorry to be so myopic.
Art
::{)
-----Original Message-----
From: Hattig, Myron [mailto:[email-masked]]
Sent: Wednesday, June 09, 1999 12:33 PM
To: 'Allison, Art'; [email-masked]
Subject: RE: IP over 1394 isoc useful?

-myron

---

From: Peter Johansson <[email-masked]>
Date: Thu, 10 Jun 1999 16:05:02 EDT

In a message dated 99-06-10 07:44:01 EDT, [email-masked]
writes:

<<Why do you need isoch for printing?>>

To eliminate the need for megabytes and megabytes of buffer in the printer.
The rasterization is done at the source and the delivery is timed to the
natural frequency of the printing mechanism.

Regards,

Peter Johansson

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

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

[email-masked]

---

From: Leonard Tsai <[email-masked]>
Date: Mon, 14 Jun 1999 09:55:15 -0700

Hi, Peter,

  megabytes of ram in printer engine also server for other purposes, so I think
this will not eliminate the buffer requirement. For video <frame> printer, the
print mechanic may not get that fast in any short time. For regular printer,
this will increase the amount of data have to move over 1394 wires since the
rendered image on host will be 100X larger than the condensed source.

Leonard Tsai
NEC
[email-masked]

-----Original Message-----
From:   Peter Johansson <[email-masked]>
Sent:   Thursday, June 10, 1999 4:05 PM
To:     [email-masked]
Subject:        Re: IP over 1394 isoc useful?

Regards,

Peter Johansson

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

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

[email-masked]

---

From: Jim Busse <[email-masked]>
Date: Mon, 14 Jun 1999 19:05:23 -0700

Peter:

     If the isoch data is synchronized to the speed of the printer, and it
     takes more than 2 seconds to print a page  (30 page/minute printer or
     slower), what happens if there is a new device connected that wants to
     be IRM in the middle of the transmission of this synchronized image?

     I am a proponent of having enough buffer allocated so bus
     perterbations don't show a usage problem.  However, the
     synchronization of electronic data to a mechanical engine is best done
     in a very captive environment, I think.

     Jim Busse
     NEC Systems Inc

______________________________ Reply Separator _________________________________
Subject: Re: IP over 1394 isoc useful?
Author:  Leonard Tsai <[email-masked]> at ccgate
Date:    6/14/99 9:55 AM

Hi, Peter,

Leonard Tsai
NEC
[email-masked]

-----Original Message-----
From:   Peter Johansson <[email-masked]>
Sent:   Thursday, June 10, 1999 4:05 PM
To:     [email-masked]
Subject:        Re: IP over 1394 isoc useful?

Regards,

Peter Johansson

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

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

[email-masked]

---

From: Peter Johansson <[email-masked]>
Date: Tue, 15 Jun 1999 05:27:07 EDT

In a message dated 99-06-14 12:56:26 EDT,
[email-masked] writes:

<<...megabytes of ram in printer engine also server for other purposes, so I
think this will not eliminate the buffer requirement. For video <frame>
printer, the print mechanic may not get that fast in any short time. For
regular printer, this will increase the amount of data have to move over 1394
wires since the rendered image on host will be 100X larger than the condensed
source.>>

Hello, Leonard.

I don't presume to speak for every company or for all applications, but I
know that some printer manufacturers already find the attractions of
isochronous compelling for this very reason!

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, 15 Jun 1999 14:30:09 -0700

Can people interested in this topic propose a list of deliverables? Once we
see the list then we can discuss how to actually deliver the item and which
WG should own the item.

Thanks,

-myron

---

From: Leonard Tsai <[email-masked]>
Date: Tue, 15 Jun 1999 17:05:22 -0700

Hi, Peter,

  May be you can help me to understand this because I thought the isoch is
guarantee time but not guarantee delivery. For printing or rendering device with
permanent output, a failure in data delivery will cause catastrophic result.
Which means you will have lines or scratches of imperfection in printing. This
means user will check and have to reprint again. So I found it hard to
understand why people think isoch is good for printing. Even for Win-Printer in
PC market, CPU wil perform hand-shaking (async) for this very reason.

Leonard Tsai
NEC

-----Original Message-----
From:   Peter Johansson <[email-masked]>
Sent:   Tuesday, June 15, 1999 5:27 AM
To:     [email-masked]
Subject:        Re: IP over 1394 isoc useful?

Hello, Leonard.

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, 22 Jun 1999 17:53:01 -0700

Given the recent traffic, I'm surprised by the silence to this query.
There is an opportunity for an informal meeting among those
interested at Oslo. We may be able to get some of the listserv
of diffserv folks interested as well. However, I would like to
have a list of proposed topics before attempting to arrange
such a meeting though.

Thanks,

-myron

> From: Hattig, Myron [mailto:[email-masked]]
> Sent: Tuesday, June 15, 1999 2:30 PM

---

From: Takeshi Saito <[email-masked]>
Date: Thu, 24 Jun 1999 01:21:17 +0900

Myron,

I am very sorry for my late response...

>> Can people interested in this topic propose a list of
>> deliverables?

I will post my "IP over iso1394" draft as WG draft soon.
(Almost same draft as I posted before.)

It deals with "How to relate IP flow to 1394 iso channel using MCAP"
and "How to control IEC61883 iso flow on IEEE1394 by MCAP".

>> Given the recent traffic, I'm surprised by the silence to this query.

I am sorry for this late...

>> have a list of proposed topics before attempting to arrange

Unfortunately I don't have a plan to attend the next IETF meeting...
(But my colleague will attend the Oslo IETF, so if there is the
meeting, he will attend. Please let me know if there is info about it.)

One comment. My previous draft discussed ISSLL (RSVP) (and diffserv)
just a little. This is because I don't think that (public) ISSLL
environment will be available soon (especially in residential area,
and in our country), and that I am more interested in AV over IP over
IEEE1394 home network (where scalability is less important, I think).
I know there are many people who think "QoS on the Internet requires
RSVP/ISSLL". I intended to design IP-iso1394 such that it can also be
used by RSVP, but more detail consideration will be needed.

Regards.

--
Takeshi "Ken" Saito

Toshiba R&D center      [email-masked]

---

From: "Joseph Joy (Exchange)" <[email-masked]>
Date: Wed, 23 Jun 1999 11:04:13 -0700

I am in favor of working on a standard for ip over 1394 isoch channels. I
will actively participate in this process and will prototype the emerging
standard on Microsoft's IP/1394 code base.

In terms of potential uses, one that springs to mind is to have 1394 as the
last link in a QoS-enabled intranet/home-network which uses RSVP to provide
end-to-end QoS.

One key deliverable is for a sender to be able to setup unicast and
multicast flows. Typically a single flow will be assigned to a single
channel, although it should be possible for the originator of a set of
unicast flows addressed to the same destination ip address to send the data
from all these flows on a single channel. To notify a potential receiver
about the mapping of flows to channels, signaling must happen at the ip/1394
layer -- basically an extension to MCAP. Mr. Takeshi Saito's draft addresses
this for the unicast flow case. If we define the format of the flowinfo
carefully, we should be able to add application-specific flow information
(such as data formats) in a backwards-compatible way.

-----Original Message-----
From: Hattig, Myron [mailto:[email-masked]]
Sent: Tuesday, June 22, 1999 5:53 PM
To: [email-masked]
Subject: Re: IP over 1394 isoc useful?

Thanks,

-myron

> deliverables? Once we