Re: [RE] Technical Feasibility (the data format swamps)
John,
>> I guess that depends whether they want to send uncompressed video.
>> This raises the issue of audio and video formats; given the scenario
The question of formats, encapsulation of formats into frames, commands
for start/stop, etc. is a _huge_ issue that multiple groups have tried
to solve and none have truely succeeded.
In the PC arena, the dominance of hardware and software vendors allows
defacto industry standards to be dictated and software drivers can be
downloaded with the product and managed by the "IT administrator".
This isn't the case with consumer devices, and the need for product
"distinction", aggressive schedules, and historical alliances can
make things difficult. And, even big CE companies have many divisions,
so commonality within one vendor is (in itself) a possibly unmanagable
problem.
I really don't know the answer to this one, and I'm not sure there
is an easy answer. Unfortunately, this problem dwarfs the issues
of synchronous cable connectivity. So, the widespread adoption of
consumer devices will probably lag the interconnect capabilities
by 5-10 years(:<).
That may sound like a pessimist, but its based on real world
experience with the 1394TA and their members. And, while its
nice to think one's own organization could do better, I think
this group was well run and others are unlikely to do it any
quicker or better.
DVJ
David V. James
3180 South Ct
Palo Alto, CA 94306
Home: +1.650.494.0926
+1.650.856.9801
Cell: +1.650.954.6906
Fax: +1.360.242.5508
Base: dvj@alum.mit.edu
>> -----Original Message-----
>> From: owner-stds-802-3-re@listserv.ieee.org
>> [mailto:owner-stds-802-3-re@listserv.ieee.org]On Behalf Of John Grant
>> Sent: Tuesday, August 31, 2004 5:09 AM
>> To: STDS-802-3-RE@listserv.ieee.org
>> Subject: Re: [RE] Technical Feasibility
>>
>>
>> At 23:47 30/08/2004 -0700, Wadekar, Manoj K wrote:
>> >Few beginner's questions:
>> >
>> >
>> >1. Looking at 3 years timeline : is GigE prohibitively expensive for
>> > Digital Homes?
>>
>> I would guess probably not for new equipment; I am not sure
>> whether significant numbers of users might have existing
>> equipmnent with 100 Mbit/s interfaces, though, and not
>> supporting 100 Mbit/s might break criterion 2 ("Compatibility
>> with the rest of 802.3").
>>
>>
>>
>> >2. If Gig switched BW is available: is overprovisioning sufficient
>> > solution for BW needs of home applications?
>>
>> I guess that depends whether they want to send uncompressed
>> video. This raises the issue of audio and video formats; given
>> the scenario
>>
>> (compressed data from wide area network or local media) -> (set
>> top box, DVD player, etc) -> network -> (presentation device:
>> TV, speakers, etc)
>>
>> the decompression needs to be done either in the stb etc or in
>> the presentation device. Currently this isn't much of an issue
>> because instead of the "network" we just have analogue cabling,
>> on which there is a small (though growing) choice of (fairly)
>> well-defined formats, and the decompression has to be done in
>> the stb etc.
>>
>> There needs to be a specification for the formats in which audio
>> and video can be sent on the network, though I think it is
>> outside the scope of this project; it's in DLNA territory (see
>> http://www.dlna.org ) though personally I'd prefer the
>> discussion to be in a more open forum such as IETF. I think the
>> choices are:
>>
>> (1) uncompressed: decompress in stb etc; presentation device is
>> kept simple, stbs etc only need to know about the formats
>> supported by their external media.
>>
>> (2) no translation in stb etc: presentation devices need to
>> support all compression formats that can arrive over any medium.
>>
>> (3) limited number of compressed formats: stb etc may need to
>> transcode between formats; number of formats a presentation
>> device has to support is bounded.
>>
>> For audio, 6 channels of 96 kHz at 32 bits per sample (as in the
>> AES3-compatible format in AES47) needs less than 20 MHz so no
>> problem with Gigabit and not much with 100 Mbit/s. Thus (1) is
>> OK for audio, and means the speakers don't need to know about
>> the different formats used by DAB, DRM, satellite, etc.
>>
>> For video, (1) needs 360 Mbit/s for 16:9 SD, and 1.25 Gbit/s for
>> HDTV so not really viable. A potential disadvantage of (3) is
>> the addition of artefacts when recompressing (e.g. wavelet is
>> really good at coding the block boundaries in DCT-compressed
>> pictures), but careful choice of the formats supported should
>> allow most of those problems to be eliminated.
>>
>>
>>
>> >3. Are there any congestion points in home topology/applications?
>> > If not, isn't deterministic latency feasible in ample-bw-scenario
>> > of GigE?
>>
>> I don't think deterministic latency is feasible in any system
>> that doesn't have connection admission control (CAC); you can
>> never be sure what competition there will be for the resources.
>>
>> This raises another big issue: connectionless vs
>> connection-oriented. Connectionless is fine for web-surfing,
>> where the client gets a few KB from one site, then clicks on a
>> link that gets a few KB from another site. It's OK for file
>> transfer, even for big files, because delay and even loss of
>> packets isn't really a problem (largely due to the incredible
>> robustness of TCP, which copes well with scenarios that can't
>> have been envisaged when it was invented). But for continuous
>> media, where you want a fixed number of Mb per second, every
>> second, from the same source to the same destination, it seems
>> crazy to have to put all the routing information (SNAP header,
>> IP header, UDP header, RTP header) in every packet.
>>
>> At the moment, when listening to the radio over the Internet, we
>> get the worst of both worlds: there's a delay while a connection
>> is made to the source, but the network doesn't take any part in
>> the connection set-up process so when the data starts to flow
>> all the inefficiencies of connectionless routing are still experienced.
>>
>>
>>
>> >4. If total BW of the pipe is >= application need, maximum latency
>> > should not be greater than PDU latency (+wire length latency: which
>> > should be small for homes)?
>> > - Jumbo frames could be an issue, however is it for home apps?
>> > - Do they use it?
>>
>> How many applications will there be on the network? Suppose 3
>> people are watching / listening to different things, and there's
>> a packet ready for each of them just as a data packet begins,
>> the latency for the first one is as you suggest, but the other
>> two have to wait longer.
>>
>> I think in the earlier discussion there was the issue that CE
>> users don't have IT departments to spec their networks. (That
>> may be a benefit: a few years ago the BBC installed a big IT
>> network for all their news reporters to use for editing news
>> items etc, and they foud that if a big story broke shortly
>> before the main news bulletins the whole network went into
>> gridlock.) They expect to be able to go out and buy a piece of
>> equipment, bring it home and plug it in and have it work (and
>> not stop anything else that previously worked from working).
>>
>>
>>
>> >Which brings back me to the question: what is the topology and what
>> >are the application characteristics (i.e. workloads)?
>>
>> It would be easy if we could say the topology is a central
>> switch from which individual connections fan out to all the AV
>> devices in the house. But it won't be like that; even if the
>> house was flood wired there will never be quite enough sockets
>> in the right place. So I think we have to assume that there will
>> be local hubs (either standalone units or built into equipment,
>> e.g. the Pioneer box in the PowerPoint file), or maybe follow-on
>> connections that allow units to be daisy-chained (which
>> topologically are very small hubs), so the total number of hops
>> could be quite large.
>>
>>
>> John Grant
>> ___ ___ ___ ___ ___ ___ ___ ___ ___
>> | || || || | | || || || || |
>> | N || i || n || e | | T || i || l || e || s |
>> |___||___||___||___| |___||___||___||___||___|
>>
>> Nine Tiles Networks Ltd, Cambridge, England
>> +44 1223 862599 and +44 1223 511455
>> http://www.ninetiles.com
>>