From owner-ip-dvb@erg.abdn.ac.uk Mon Sep 1 14:49:24 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h81DmtGL003947 for ; Mon, 1 Sep 2003 14:48:55 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h81DmsZg003944 for ip-dvb-subscribed-users; Mon, 1 Sep 2003 14:48:54 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley-ipv6.erg.abdn.ac.uk [IPv6:2001:630:241:1:20a:95ff:fe7d:5f0c]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h81Dm7GM003912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 1 Sep 2003 14:48:08 +0100 (BST) Message-ID: <3F534E18.6050805@erg.abdn.ac.uk> Date: Mon, 01 Sep 2003 14:48:08 +0100 From: Gorry Fairhurst Organization: Univesrity of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: Re: Corrections/Evolutions for ULE draft (Ethernet type codes) References: <3F4E3492.1090007@6wind.com> <3F4E49BF.2030403@erg.abdn.ac.uk> <3F4F0C15.6030502@6wind.com> <01e601c36e11$e0abf110$c602a8c0@copernicus> In-Reply-To: <01e601c36e11$e0abf110$c602a8c0@copernicus> Content-Type: multipart/alternative; boundary="------------020104010809080104010607" X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk This is a multi-part message in MIME format. --------------020104010809080104010607 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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: >To: >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 >> >> >> > > > > > --------------020104010809080104010607 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
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

    



  
--------------020104010809080104010607-- From owner-ip-dvb@erg.abdn.ac.uk Mon Sep 1 17:42:51 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h81Gg2GL010642 for ; Mon, 1 Sep 2003 17:42:02 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h81Gg1kO010641 for ip-dvb-subscribed-users; Mon, 1 Sep 2003 17:42:02 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h81GfYGL010616 for ; Mon, 1 Sep 2003 17:41:34 +0100 (BST) Received: from 6wind.com (nas-cbv-6-62-147-174-75.dial.proxad.net [62.147.174.75]) by postfix3-2.free.fr (Postfix) with ESMTP id 876F9C3D0; Mon, 1 Sep 2003 18:41:33 +0200 (CEST) Message-ID: <3F5376BA.5020108@6wind.com> Date: Mon, 01 Sep 2003 18:41:30 +0200 From: Alain RITOUX User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: fr-fr MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: Re: Corrections/Evolutions for ULE draft (Ethernet type codes) References: <3F4E3492.1090007@6wind.com> <3F4E49BF.2030403@erg.abdn.ac.uk> <3F4F0C15.6030502@6wind.com> <01e601c36e11$e0abf110$c602a8c0@copernicus> <3F534E18.6050805@erg.abdn.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Gorry Fairhurst wrote: > > 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. I don't understand the link between type field and length ? maybe because niot really familiar with LLC. > 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? To have separate realms, is good for we don't have to rely on missing types to be defined elsewhere and allows to keep ether-like type to be used, so keeping ythis encpas wide open for many things, wiothotu any new stuff to be defined ;-) So that's fine for me, but how do we see wether a type field is small or big type ? is there for example a first byte value forbidden in ether-type ? About control packets for link testing, what do you have in mind ? for I wouldn't go into the PPP-LCP-NCP direction ... > > > 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: Yep, if no link provides it, MTU will never increase :-( with what i've heard about some errors, I'm fine wiht 16 K. so wiith this the 2 MSB of this field should be defined as : MUST be set to 0 by the sender, and MUST be ignored by the receiver. Cheers. Alain. From owner-ip-dvb@erg.abdn.ac.uk Mon Sep 1 18:42:29 2003 Received: from mavis.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h81Hg5GL012896 for ; Mon, 1 Sep 2003 18:42:05 +0100 (BST) Received: (from majordomo.lists@localhost) by mavis.erg.abdn.ac.uk (8.12.9/8.12.2/Submit) id h81Hg562012895 for ip-dvb-subscribed-users; Mon, 1 Sep 2003 18:42:05 +0100 (BST) X-Authentication-Warning: mavis.erg.abdn.ac.uk: majordomo.lists set sender to owner-ip-dvb@erg.abdn.ac.uk using -f Received: from erg.abdn.ac.uk (gresley-ipv6.erg.abdn.ac.uk [IPv6:2001:630:241:1:20a:95ff:fe7d:5f0c]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h81HfcGM012868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 1 Sep 2003 18:41:40 +0100 (BST) Message-ID: <3F5384D4.8010001@erg.abdn.ac.uk> Date: Mon, 01 Sep 2003 18:41:40 +0100 From: Gorry Fairhurst Organization: Univesrity of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ip-dvb@erg.abdn.ac.uk Subject: Re: Corrections/Evolutions for ULE draft (Ethernet type codes) References: <3F4E3492.1090007@6wind.com> <3F4E49BF.2030403@erg.abdn.ac.uk> <3F4F0C15.6030502@6wind.com> <01e601c36e11$e0abf110$c602a8c0@copernicus> <3F534E18.6050805@erg.abdn.ac.uk> <3F5376BA.5020108@6wind.com> In-Reply-To: <3F5376BA.5020108@6wind.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean, Found to be clean Sender: owner-ip-dvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ip-dvb@erg.abdn.ac.uk Ethertypes were originally by Xerox under the DIX framewwork. After sepcification of IEEE 802.3, Ethertypes less than 1500, became a length indicator that was user to discriminate LLC frames. Hence any Ethertype <= 1500 is an LLC frame, and the Ethertype value indicates the LENGTH of the payload. Historic note, when this was done, some protocols had DIX Ethertypes less than 1500, these were re-assigned to the IEEE, and new values allocated for the protocols. So, if we adopt this scheme, all values less than 1500 would be IANA assigned (if we can get the IETF to agree) and all values above 1500 would follow the IEEE/DIX type assignments for Ethernet. If we wished to support LLC - then we would add one IANA assigned type to indicate this, and the Length would already be carried in the SNDU header - there are no we have two separate realms. Gorry Alain RITOUX wrote: > > > Gorry Fairhurst wrote: > >> >> 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. > > > I don't understand the link between type field and length ? maybe because > niot really familiar with LLC. > >> 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? > > > To have separate realms, is good for we don't have to rely on missing > types > to be defined elsewhere and allows to keep ether-like type to be used, so > keeping ythis encpas wide open for many things, wiothotu any new stuff > to be > defined ;-) > So that's fine for me, but how do we see wether a type field is small or > big type ? is there for example a first byte value forbidden in > ether-type ? > > About control packets for link testing, what do you have in mind ? for I > wouldn't go into the PPP-LCP-NCP direction ... > >> >> >> 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: > > > > Yep, if no link provides it, MTU will never increase :-( with what > i've heard > about some errors, I'm fine wiht 16 K. so wiith this the 2 MSB of this > field should be defined as : MUST be set to 0 by the sender, and MUST be > ignored by the receiver. > > Cheers. > Alain. > > >