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

["Thomas 'Dent' Mirlacher" <dent@cosy.sbg.ac.at>]

--snip/snip
> > 
> >  1B pointer-field
> > 12B MPE (flags+MAC)
> >  8B LLC+SNAP
> >  4B CRC
> > ---
> > 25B     for MPE         ~ 1.1% overhead (MTU=1500)
> > 
> 
> or 25% for 100B, 63% for 40B, etc. - assuming PACKING is used.

you can also use PACKING with sections (even multiple times per TSC)

> >  2B length+flags_for_MAC_type
> >  2B type
> >  6B MAC
> >  4B AF_lenght
> > ---
> > 14B     for the new schem ~ 0.9% overhead
> > 
> > ... did i miss anything here?
> 
>   2B length+flags_for_MAC_type
>   2B type
>   ---
>   4B     for the new scheme 

i was assuming the case where you need to have a destination
MAC address.
and doesn't the new scheme require an AF at the end of a PDU?
	(which is at least one byte or 4 byte when another
	 PDU is packed into the cell)

> 0.3% overhead (MTU=1500)
> or 4% for 100B, 10% for 40B, etc.

right.

> - All assuming that you don't look at the detail of padding, and PUSI 
> pointers, etc.

sure.

--snip/snip

> > the format is not MPE compatible in any way, but yes, an application
> > could use the formats on the fly. - but the problem here is: if the
> > "application" decides to do that, the whole point of the fields
> > goes away, since the application shouldn't be aware of the topology.
> > 
> > - it is the gateway which should know the topology, but when changing
> > topology, that means changing the gateway - is that alway the case?
> > (nowadays yes, but do we want to do this also in the future?)
> 
> Actually, I'm not sure we should have 'MAC destination-only' as an option....
> but I'm happy to define it for the moment.

at least for filtering at the receiver side, as well as L2 switching
it could be useful (and you probably don't need the source in that
case)

	++Thomas

-- 
in some way i do, and in some way i don't.