[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Réf. : Re: Alcatel Space interest about IP/DVB



From: "Lloyd Wood" <l.wood@eim.surrey.ac.uk>
To: <ip-dvb@erg.abdn.ac.uk>
Sent: Wednesday, April 17, 2002 4:07 AM
Subject: Re: Réf. : Re: Alcatel Space interest about IP/DVB


> On Tue, 16 Apr 2002, Kearney wrote:
>
> > > By "Ethernet-like" we only mean "connectionless layer 2 based on
broadcast
> > > medium".
> > Question - why does it have to be connectionless?
> > Most of the applications are anyhow sessio-oriented - TCP, HTTP, and in
> > particulatr multicast applications are based on the concept of a
session.
>
> HTTP wasn't conceived as being session-like. Not all multicast
> applications are based on a sessoin either.
>
you are right - it was designed as a request/reply protocol but operating on
top of TCP which is session/connection oriented. And HTTP1.1 has taken some
of the liberty and recommends now a "persistent" connection.
But let's look at the lower protocol level. Whatever the size of your "page"
you are sending or returning - you will have to allocate channel bandwidth
for it, and chances are you will not do this for a PID at a time but on a
more permanent basis.

> > If you "tune" your receiver to a PID you are basically opening a
> > session - so why wouild you like to have the next higher layer
> > (link/encapsulation) connection-less?
>
> that's exactly what the connectionless HTTP/1.0 does over the TCP
> session; it ignores TCP session state (arguably lousy programming, and
> slowly addressed in 1.1 implementations). But it made for ease of
> specification and implementation.
>
as I said above - it didn't care at all how the channel allocation strategy
could cope with this - and that's one of the problems we ought to address
here.

> If you look at protocol stacks you'll see connectionless/session
> alternating as you go through the layers.
>
> If you "tune" your receiver to a PID you might be joining a broadcast
> session, and if several terminals share the same PID...
>
I see this as the most important aspect - economics of satellites require
that you do as much broad-/multicasting as possible since point-to-point
services have to cover the full cost of the channel wehreas ***cast shares
the cost.
If you "tune" your receiver to a PID you are basically doing the same thing
as if you connect your laptop to a LAN - you will be sharing the total
bandwidth available for this PID. So you could run point-to-point service
antop of a shared PID if you include a "label/address" in the encapsulation
header.

--Hrst Clausen ("kearney")
> L.
>
> <L.Wood@surrey.ac.uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>
>
>