Subject: Re: IP over 1394 isoc useful?

From: Takeshi Saito <[email-masked]>
Date: Tue, 8 Jun 1999 01:03:24 +0900

Myron,

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

I also think that we cannot expect the Internet backbone (public Internet)
supporting isoch traffic in the near future.

>> If the Internet cannot support isoch traffic, we are left with only
>> considering isoch traffic that spans the home network.

Yes, this is what I think of.

>> 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).

I don't know whether video is the only iso appl. Video, audio, and some
other applications are possible.

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

I agree.
(Previously I was ATM guy. I believed "every node will connect to ATM."
All of you know this was just a dream...)

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

Well, it depends. High speed intra-room network (based on fast ethernet,
fast phone line, or fast radio LAN) will be available within a few years.
(But I cannot say they will definitely be prevailed...)

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.

Another idea like "printer data over IP over iso 1394", "IP based AV
server connected to 1394" will also be available, I guess.

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

I don't mind how AV/IP waste the bandwidth (if not extreme), because
we don't suffer "lack of bandwidth" problem inside home.
To examine whether IP based AV application is nice or not is more
important now.

This is similar to that "video over ATM is better than video over IP
because ATM uses less bandwidth."  I guess PC based application will
be more happy if it is IP based because of great development environment
of IP applications, and the skill of the programmers.

Whether IP based appliances is possible or not is another debating issue.
I don't think we have to answer "no" to this question now.

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

Regards.

--
Takeshi "Ken" Saito

Toshiba R&D center      [email-masked]

---

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

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: Tom Suters <[email-masked]>
Date: Thu, 10 Jun 1999 13:43:34 +0200

> transmission. So I want to have a mechanism to bind IP and iso 1394.

Although doing video over IP over 139 is nice as experiment, I don't see
the real need for it in the near future in the home if we already have
video over 61883 over 1394. The 61883 formats (MPEG) will be the main
(and only?) digital real-time streaming video format deliverered to and
existing in the home for entertainment purposes for a long time. Whether
we need to work on a video over IP standard should be determined by the
need of an application for which no solution yet exists. Non-real time
transfers can be solved today with existing protocols including SBP-2,
DPP, (non-isoch) IP over 1394, ...

If this group decides to do the isoch-IP over 1394 work, at least the
61883 CIP format and CMP protocols should be used as the basis to
prevent that new real-time protocols (and hardware) are needed.

> server connected to 1394" will also be available, I guess.

Why do you need isoch for printing?

> Regards.

Kind 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]
+===========================================+