Re: [RE] Technical Feasibility
<DC>Comments follow</DC>
Dirceu Cavendish
NEC Labs America
10080 North Wolfe Road Suite SW3-350
Cupertino, CA 95014
Tel: 408-863-6041 Fax: 408-863-6099
-----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").
I think we should assume 100M/1G interfaces...
>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.
<DC>
Video format is indeed an issue. However, I believe that (echoing John's
concerns) regardless the video encoding, we need to show that
interfering traffic can cause "glitches" in the video application...
</DC>
>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.
<DC> Firstly, our scope does not involve IP layer/protocols (other than
IP addresses). Second, connections/connectionless issue might not make
sense in a "single link" scenario. Since we are a .3 study group,
topology discussions might be out of scope. I haven't worked under .3
(Im a .1 voter), so I defer this discussion to experienced .3 people.
</DC>
>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.
<DC> Again, before we engage in the topology discussion, we must decide
whether we should keep our scope within the single link scenario (.3)...
</DC>
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