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
> 
> > > > Without layer 2 source address, how do we recognize our own datagrams,
> > > > when we get them back on the link several ms after sending them.
> > > > ...
> > > >
> > > > If we are really convinced that in some cases either the destination
> > > > and/or source MAC address are uneeded, and if the goal is to save some
> > > > bits not having them, we could use 2 bits out of the length field
> > > > The length field would then be 14 bits ([0,16383])
> > > > MAC_FLAG
> > > >
> > > > 00 : no dst MAC, no src MAC
> > > > 01 : dst MAC, no src MAC
> > > > 10 : src MAC, no dst MAC
> > > > 11 : dst MAC, src MAC
> > > >
> > > > MAC is IEEE 48 bits
> > > > no dst MAC is equivalent to a broadcast: ff:ff:ff:ff:ff:ff
> > > >
> > > > +--+--------------+----------------+----------
> > > > |00|    length    |      type      |Payload
> > > > +--+--------------+----------------+----------
> > > >
> > > > +--+--------------+----------------+-----------  --+----------
> > > > |01|    length    |      type      |48 bits dst ~  | Paylaod
> > > > +--+--------------+----------------+-----------  --+----------
> > > >
> > > > +--+--------------+----------------+-----------  --+----------
> > > > |10|    length    |      type      |48 bits src  ~ | Paylaod
> > > > +--+--------------+----------------+-----------  --+----------
> 
> 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 ...)
> 
>         ++Thomas

Not so.

First, there is no section filtering, etc. So the processing is very simple.

Second, the encapulsation byte overhead is actually much better.
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.

Native IP applications could still use 00 format, if they like, and
"MPE-like" applications could yse 01 encoding if they need it.

----

The main advantages seem to be:

(1) For type 01, 10 there is a more efficient header. In the previous
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?
- 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.
- 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'. 

(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.

thoughts?

Gorry