Re: Self routing

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

From: "Gorry Fairhurst" <gorry@erg.abdn.ac.uk>
Sent: Tuesday, April 23, 2002 4:02 AM
Subject: Re: Self routing


> Marie-Jose Montpetit wrote <forwarded by admin for ip-dvb>:
>
> I would be worried to propose a scheme based on user traffic statistics of
> today. Yes there are huge numbers of IPv4 ACK packets out there and yes a
> ton of http: traffic too. This is April 2002. Deploy IPv6 in a grand scale
> and the 40 bytes traffic will go down significantly. Non TCP or http:
based
> protocols will have other sizes, will they dominate? Don't know...
>
> If we want to change MPE then the solution should be robust enough to
> support the changes the other IETF groups will propose... BTW I would
> recommend the group works on a draft on the requirements (look at what
NSIS
> did). It would foster a better discussion about what we are trying to
> achieve here.
>
> Marie-Jose
>
I don't think we want to change MPE but come up with an alternative, more
efficient and more flexible solution.
I agree with Gorry and Harri concerning header compression - we should keep
this in mind and come up with a design that fully supports it, but we should
not include it in the encapsulation.


>
>
> Ghassane Aniba wrote:
> >
> > Hi,
> > i've a remark:
> > if we have 96% of traffic with 1500 or 576 bytes, and 40 or 48 bytes, we
> > found this:
> >
> > if we use the SNDU encapsulation ( + 8 bytes for each IP packet), we
> > will have this results:
> >
> > 148 bytes free  ----->  1508 bytes (9 * 184 bytes)
> >
> > 152 bytes free  ----->   584 bytes (4*184 bytes)
> >
> > 128 bytes free  ----->   56 bytes ( 1 * 184 bytes)
> >
> > 136 bytes  free ----->   48 bytes ( 1 * 184 bytes)
> >
> > this results confirm that we have enough space for adding our labels.
> > Although, if we though about using a pointer, and a @ling_sat for each
> > fragment of SNDU, we will have other results.
> >
> > I'm thinking about adding another label, to the @link_sat_adress (I know
> > that most of us, will say that's a lot of overhead, but i'm sur that it
> > will be interesting).
> > The name of label, will be " label_sitching". if you remember the
> > descriptor which i've proposed, we foung this field.
> > For each MPEG2-TS packet we will add 4 bytes, for this new label. We
> > suppose that we have in maximum 32 spots. Each bit of the
> > label_switching in the MPEG2-TS packet, will specify if this spot is
> > concerned by this packet of not.
> > So, we will eliminate the switching table from satellite, and having in
> > her place, a smaller tables in each terrestrial terminal.
> >
> > |---------------|------------|-----------------|------------------|
> > | Mpeg2 Header  | @link_sat  | label_switching |  SNDU fragment   |
> > |---------------|------------|-----------------|------------------|
> >      4 bytes       3 bytes        4 bytes             177 bytes
> >
> > With this new label, we will find that the nombre of MPEG2-TS packet for
> > each SNDU didn't change.
> >
> > Aniba.
I like this 177 bytes number - this fits very well into todays 16/32 aligned
architectures and makes for efficient moves.

one more point: you said that you only use 4 bits of the 13 bits of the PID
since your hardware can scan only a maximum of 20 PIDs - who or what is
scanning your 24 bits of the link_sat field? I suppose this is a separate
box - i.e. one protocol layer up.

--cls