Re: Subject: I-D ACTION:draft-clausen-ipdvb-enc-00.txt

["Kearney" <clausen@cosy.sbg.ac.at>]

Harri and Gorry,

> > Couple of quick comments, more may follow::
> >
> > - Have you calculated, what is the actual efficiency
> >   gain compared to MPE (1 or 2 % ?) ?
>
> Well, that depends...
>
> First, processing COST is significantly smaller
> - far fewer fields to process and decode.
>
The measurements we did about 2 years ago show that the bulk of the packets
on the forward channel are either 576 or 1500 bytes - there are a few
percent with 512 bytes and some control packets with 40 and 48 bytes - the
rest is more or less insignificant. Be careful when interpreting this - a
new "killer" application such as e.g. Napster might change this profile very
quickly - we saw this in the '90-ies when the Web cam up and made most
statistics obsolete overnight.
On the return channel of course the majority are the short 40+48 byte
packets which TCP gerenates and then some.
However, think of Haralds remark the other day - other cell sizes besides 48
and 184 might be used in other wireless and satellite systems - and the
overhead if you do NOT pack depends significantly on the cell size.

> Second, there is a small gain compared to the best case for MPE,
> and a much larger gain compared to the worst case (small packets,
> unpacked).
>
> Some analysis of MPE was previously sent to this list at:
> http://www.erg.abdn.ac.uk/users/gorry/ip-dvb/docs/Overhead-Analysis.doc
>
yes - and if you look at the green curves with their sawtooth
characteristics - every transmission system with fixed length cells exhibits
this - except if you do it as SDH/Sonet does it with pointers and a
"floating" container. You could of course optimize by choosing a SNDU block
size which nicely fragments into cells - but if anything should change, the
cell size or the block size, then you end up on top of the inefficiency
peak. Ergo- we should pack.
> >
> >   (I assume that in dowstream most packets are rather big)
> >
> > - Related to that, is it justified to do this without taking
> >   header compression into consideration from the beginning ?
> >
> I believe you are right, we SHOULD look at header compression,
> you'll see that the proposed scheme seems very suited to use
> with a scheme such as ROHC header compression, however the
> details of this scheme are still being pursued by the ROHC WG.
>
AGREE - we should really look at header compression but the question is
whether ROHC is applicable for a simplex channel. As far as I know ROHC
makes use of a more or less periodic handshake between the compressor and
the decompressor - we might have to resort to some PSI tables for conveying
this "refresh" information.
But we really should look at header compression right away!

> I think header compression is going to be important for many
> applications, - one obvious case is transmission of small
> IPv6 datagrams over links with limited bandwidth.
>

> > - Do you, by any change, know who has the IPR for the
> >   "MPLS label" in adaptation field ?
> >
>
> Not sure what you mean...
>
me too

--Horst