Corrections/Evolutions for ULE draft (Ethernet type codes)

[Gorry Fairhurst]

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 at 6wind.com>
>To: <ip-dvb at 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
>>
>>    
>>
>
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erg.abdn.ac.uk/pipermail/ip-dvb/attachments/20030901/32351284/attachment.html>