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