Re: Corrections/Evolutions for ULE draft (Ethernet type codes)

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

A) OK. so my take on the type field is:

(i) I don't worry about using 1B rather than 2B for a type field. There's no
real added CPU cost, and the extra bandwidth consumed on the link is marginal
for just one byte. I vote we stick for 2B.

(ii) I like Ethernet-style type fields, because most devices communicate using
these values, it's easy to find the appropriate set of types, and they cover
most uses - albeit no support for ROHC, etc, as in (thread below).

(iii) Finally, I note there is an overlap in function in ULE and also in the
alterantive ID on encapsulation. Both current specs include
separate length and type fields. If the type field is small,
then this also indicates length (according to IEEE 802 LLC).
So, the SNDU would have two length fields. I don't like this
- it gives the opportunity for one of these values
to be wrong - always risky for an implementation.

So, I propose we re-define the type field this way:

Small type values: IANA Assigned, using a registry.
    - In this space we may define any other specific type we need.
    Examples are:
       LLC header follows in SNDU
       Control packet for link testing  
       ROHC type ***if*** required, ***and*** no Ether type assigned

Large type values: To follow DIX/IEEE assignements (not using LLC).

Is this clever /stupid /ok?

B) Now, the length issue:

OK, so we could argue about whether MPEG-2 will ever be at the "core"
or not, but the key point was that if ***ANY*** parts of the Internet
evolve to use a large PMTU, then it would be better to allow it over MPEG-2.
If this happens to be a satellite link, the larger MSS would significantly
benefit TCP. Since the IETF has started work on next generation PMTUD,
we should allow operators in future support this. In short:

I'd think it reasonable we mandate a CRC-32, and allow 16 KB SNDU.

Any other comments? Anything we've missed?

Gorry

----

Marie-Jose Montpetit wrote:

I actually doubt that any satellite system will ever be attached directly to
the core networks :-)

I am more concerned by the probability of loss in the satellite channel (no
flame from the PHY guys please, I know the link is almost error free but
almost is not fully). Hence the probability that one segment of a packet is
lost is proportional to the number of fragments and then the whole things
may be lost (if no higher layer recovery mechanisms) so much to say for the
savings of encapsulations. I would vote for 16k.

Marie-Jose

----- Original Message ----- 
From: <alain.ritoux@6wind.com>
To: <ip-dvb@erg.abdn.ac.uk>
Sent: Friday, August 29, 2003 4:17 AM
Subject: Re: Corrections/Evolutions for ULE draft


  

Gorry Fairhurst wrote:

    

There is one thing I'd like to get a feeling for from the list:

   Do we need to support a maximum paylaod size of approx 64KB?
I've asked this several times, and most people seem to agree we don't
need to support payloads this big, nor is it likely to be significant
issue for this type of network in the future. I'd advocate at least 16
KB, could we live with a little less than 32 KB as the maximum payload
size??? Is there anyone with other views out there?
Thoughts?

      

Indeed, I once proposed to reduce it more than that, but mainly I
was thinking "ethernet", and I see now that in the core, MTU are
getting higher !!
On FreeBSD implementation ATM interface have ~9K MTU. And I've read
something about some links also with 9K MTU. I feel comfortable
with 16K, which leaves 2 bits for any creative usage ;-)

btw : what about next header in ULE method, for as alignement is
clearly not aimed, maybe 1 byte is enough, reducing encaps overhead
from 8 to 7. And to kkep possible type extension (if 256 space
gets exausted, the mlength field, could be specified to cover
type-field + payload + CRC, instead of just  payload + CRC

still "next header" considerations:  if is is an ether_type, there
can be pb for non-defined ether_types, such as ROHC :-(
and so it would block the draft UNTIL and ether type is (ever?)
adopted, because choosing a non-ether-type for one of the protocols
might result in a future conflict.
same thing for PPP-types : I haven't found PPP-type for MPLS

still with the same subject : are two differnet values needed for
ROHC4 and ROHC6, for ROHC packets are asociated to specific flows
that share some common info (such as addresses, and especially IP
version!). I had a look a RFC3241, and there is no ROHC-v4 and
ROHC-v6 separation for PPP, rather a separation between
ROHC-with-small-CID ROHC-with-large-CID, which is said not to be
needed ("p2 ROHC does not require that the link layer be able to
indicate the types of datagrams carried in the link layer
frames.") ????
So, I think, a single netx header value could be used.

Your thoughts ?

Cheers.
Alain.
-- 
Alain RITOUX
Tel +33-1-39-30-92-32
Fax +33-1-39-30-92-11
visit our web http://www.6wind.com