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