[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPR & other considerations (RE: Subject: I-D ACTION:draft-clausen-ipdvb-enc-00.txt)
- To: ip-dvb@erg.abdn.ac.uk
- Subject: Re: IPR & other considerations (RE: Subject: I-D ACTION:draft-clausen-ipdvb-enc-00.txt)
- From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
- Date: Mon, 22 Apr 2002 09:49:19 +0100
- Organization: ERG
- References: <>
harri.hakulinen@nokia.com wrote:
>
> Moro, (as they say in this town istead of hello)
>
> > -----Original Message-----
> > From: ext Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk]
> > Sent: Friday, April 19, 2002 3:15 PM
> >
> > harri.hakulinen@nokia.com wrote:
> > > - 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.
>
> I think that "processing cost" is really a non argument here.
> In my opinnion the possible new encapsulation needs to have
> mandatory header compression support, and in that case that
> cost will anyway be much higher than with current MPE.
>
This is an interesting debate - but, I'm not sure I entirely agree.
Lower level processing (operating on each SNDU or part of, rather
than packets which have passed a "filter" and will be forwarded
ultimately) is always more painful than simply servicing a queue
of filtered packets (e.g. within a device driver), which is where I
would expect header compression to be implemented.
The issue is also that using header compression, the SIZE of a
SNDU may be very small (few-tens of bytes), then MPE/section
overhead becomes very large in comparison.
> > 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-Ana
> > lysis.doc
>
> It is totally different thing to recommend the use of section
> packing of the existing standard than to propose a new standard ..
>
Sure, well an alternate/complementary approach would be to define
a profile for MPE which says exactly what fields are to be used,
how options are to be defined, etc. Given the expected continued life
of MPE, which will be long in some applications at least, this
could be a useful document - would you be willing to write it?
I would expect any signalling protocol that comes from this
group to address MPE and also any new encapsulation - this
would also be useful as a basis for this discussion.
> > > - Do you, by any change, know who has the IPR for the
> > > "MPLS label" in adaptation field ?
> >
> > Not sure what you mean...
>
> By knowing something about "the state of art" in this subject,
> I would classify that idea as very easy to patent.
>
> In the old DAVIC times some Japanese company proposed something
> similar in the scope of PES for IP headers (instead of MPLS),
> but I don't remember anymore, what was the company and I am too
> lazy to do patent search right now.
>
> Bottom line(s)::
>
> Be prepared to find some resistance towards solutions that are
> possibly under heavy IPR, especially if that is owned by companies
> that are outside of DVB/Etsi scope.
>
The IETF has a stated policy of choosing non-patent solutions where
possible. I personally would support this whole heatedly. I would
like to see an open standard appear, if this is possible.
> Minimum req. in this subject is to get "IETF IPR statements" from
> authors, but in this case it doesn't necessarily help much, because
> we don't know to what companies they may be connected.
>
YES.
> //Harri
>
<<snip>>