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

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

--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)

 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?


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)

> 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?)

> ----
> 
> 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?

this could also be a good thing (e.g. for delay jitter)

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

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

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

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.