Re: Corrections/Evolutions for ULE draft

["Marie-Jose Montpetit" <mariejose.montpetit@verizon.net>]

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
>