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

[Dr G Fairhurst <gorry@erg.abdn.ac.uk>]

Thomas 'Dent' Mirlacher wrote:
> 
> --snip/snip
> 
> > > in case "10" you're exaclty at the bandwidth-consumtion where MPE is
> > > (well +/- 2 byte per PDU)
> > >
> > > also it's a point to discuss if you need all the fields in the MPE
> > > header - but at least it's a start, after having the requirements
> > > to go from (probably most of the people wouldn't be happy with the
> > > MAC address layout in the MPE header ...)
> >
> > Not so.
> >
> > First, there is no section filtering, etc. So the processing is very simple.
> 
> well, if you assume you will just receive MPE sections you can also
> skip sektion filtering. - and with the new encapsulation, tou can
> only transport this encapsulation per PID also.
> 
> > Second, the encapulsation byte overhead is actually much better.
> 
> well, the %tage depends on the MTU, and actually it is about
> 
>  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.

>  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 

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

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

> don't misunderstand me here, i'm not a proponent of MPE, nor against
> a new encapsulation - i just want to view this discussions in a
> critical way, and probably ask to clarify some things (for myself)
> 

Agreed, maybe someone should some real calculations...

> > You have in this case full MAC source and destination address, type. In some
> > applications this is needed. If you want to do that in MPE, you have
> > to add an LLC/SNAP header - that's a lot more overhead.
> 
> well, LLC/SNAP includes "overhead" which is the LLC + 3 byte org code,
> yes.
> 
> > Native IP applications could still use 00 format, if they like, and
> > "MPE-like" applications could yse 01 encoding if they need it.
> 
> 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.

> 
> > ----
> >
> > The main advantages seem to be:
> >
> > (1) For type 01, 10 there is a more efficient header. In the previous

10 should have been 11.

> > scheme in the draft these require an extra TYPE field - part of the
> > fixed format header which then indicates this is a bridged payload,
> > and carries the MAC layer information (addreses and ether-type).
> >
> > The main drawbacks I can see of this approach are:
> >
> > (1) We reduce maximum SNDU length from nearly 64 KB to just udner 16 KB.
> > - Is that an issue?
> 
> this could also be a good thing (e.g. for delay jitter)

Yes.

> > - I can see why 4 KB is a useful size, and also, posisbly 10 KB, do we
> > need more 16 KB (or so) packets in this context?
> >
> > (2) The lower layer processing now has to be aware of the various
> > format options, previously all frames used the same initial format.
> 
> if you take a look at 802.11, the lower layers also need to be aware
> of special formats (even the meaning for address-fields could change)
> 
> > - But probbaly one wants to do level 2 processing of MAC addresses
> > anyway (if present) so, not sure the variable format is an issue?
> >
> > (2) We have only one unused format indicator '11'.
 
whoops, the "odd" one is '10' as Patrick said, 11 is needed.

> ... again: if we would have requirements we could reserve a byte, or
> a nibble from the length (i will stop talking about requirements now)

Yes, I'd advocate '01' as reserved.

OK.

> > (3) We fix the PDU format for 01, 10 based on 6B MAC addresses only.
> > It may be difficult to use a larger/smaller value in the future.
> 
A
> you could reserve more space for the address, and use it for MAC addresses,
> now - and later for some other addressing-scheme (this would require a
> version field)
> 
>         just my $0.02
> 
>                 ++Thomas
> --
> in some way i do, and in some way i don't.