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

[Lloyd Wood <l.wood@eim.surrey.ac.uk>]

On http://www.watersprings.org/pub/id/draft-clausen-ipdvb-enc-00.txt:

On Thu, 25 Apr 2002, Gorry Fairhurst wrote:
> Haitham Cruickshank wrote:
> > * I think it will be beneficial to add a small section about the main
> > problems with current MPE (such as large overheads and complex options,
> > implementation compatibility, etc ..) and provide a brief comparison
> > with the new leaner encapsulation.  This will help a lot the people who
> > are not familiar with MPE.
>
> I disagree - in that this is a protocol spec, however we wondered
> whether to update the requirements ID:
>
> or should we create a new ID with this infromation?

isn't that really part of the protocharter of the protoWG, justifying
the WG's purpose for existence - which the requirements draft could
include?


> > 1. The size of "type" field in the SNDU encapsulation format (figure
> > 1).  Why do we have to stick with two bytes size (16 bits) where the
> > types are only 4 types only (ipv4, ipv6, mpls and Br. Ethernet)
>
> But, it's not clear to me, there may be some more...
>
> e.g. there are two different MAC bridge encapsulations in use elsewhere
> in the internet and, we *DO* plan to support ROHC.

(ROHC has ethertypes these days?)

on type, I imagine 0x0000 is reserved as it is for ethertypes (making
it available for local use?)

$ The special value 0x0000 indicates that there are no further SNDUs
$ within the current TS packet (see section 5.1)

what is type set to when length field is zero (final frame)? Does it
matter at all (for multiplexing, I think so)? how will this
affect/weaken CRC computation of the final frame? (okay, depends on
CRC choice, but something to think about.)

You'd have to have a lot of SNDUs in the TS to justify an empty SNDU
rather than the overhead of a couple of first/intermediate/last bits
per SNDU.

> > 2. Is there really a need for CRC ?
>
> A dificult one.

The CRC is also needed to protect the length and payload type fields,
so that you don't attempt to parse gibberish. if you're going to
checksum length+type or payload, you may as well do the whole thing
so that reassembly can be checked.

> It would seem that bit errors should be rare, due to the
> under-lying coding in most cases. But the IETF has previously suggested
> we should be certain there are no undetected bit errors to the same
> level of certaintity as a 32-bit CRC would give.  So, my main worry
> is reassembly bugs and hardware-related transfer problems, rather than
> the physical channel. Recent experience shows we should NOT ignore such
> things, they happen often in IP Routers, so why not here? I personnaly
> would advocate at least a CRC-16.

A trailing CRC should be slightly better for spotting router
overwrite/truncation problems.

A minor beef with the draft: section 4 defines (is titled) the SNDU
format, but the SNDU is the datagram encapsulated inside this,
according to the earlier SNDU definition anyway. When the CRC is said
to protect the entire SNDU I presume it means the outer SNDU, not the
inner SNDU which is the payload. This isn't stated explicitly, and you
have to read carefully to distinguish between SNDU (the carrying
frame) and SNDU field (the payload). I'd be tempted to dump the SNDU
term entirely, or use PDU for the payload (as in ENCAPSULATOR
definition), so that the SNDU field is a PDU field.

Having a maximum length of 65531 (because you've reserved 4 bytes for
the CRC, but aren't subtracting the length and type field lengths?
Doesn't gel with length=0 for checksummed final empty frame)  will not
play that nicely with jumbograms imo. RFC791 lets even IPv4 go to
65535 bytes - the sort of thing the IESG would pay attention to.

(Some security text is mandatory for drafts these days. But is the
SNDU the right place to do link security? I suspect not.)

L.

<L.Wood@surrey.ac.uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>