Re: [16NG] WG last call on draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-02 + RE: regarding my comments on MTUs

["Riegel, Maximilian (NSN - DE/Muenich)" <[e-mail]>]

If 'L2 tunneling' is replaced by 'L3 tunneling' I am fine with option 3.
There are too many protocols and options in 'L2 tunneling', to make a
recommendation without providing further details. Burcak may have one
particular solution for fixed and nomadic deployments in mind, which
works well, and I see issues with L2 tunneling in a mobile environment.

Bye
Max

-----Original Message-----
From: ext Samita Chakrabarti [mailto:[e-mail]] 
Sent: Thursday, April 10, 2008 11:01 PM
To: Riegel, Maximilian (NSN - DE/Muenich); 'Burcak Beser'; 'Wesley
George'
Cc: 'Samita Chakrabarti'; 'gabriel montenegro'; [e-mail]
Subject: RE: [16NG] WG last call on
draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-02 + RE: regarding my comments
on MTUs

Hi Max,

Not clear to me whether you are also supporting option 3 as suggested
below
by Burcak. Please confirm.

Thanks,
-Samita

>-----Original Message-----
>From: Riegel, Maximilian (NSN - DE/Muenich)
>[mailto:[e-mail]]
>Sent: Thursday, March 27, 2008 10:17 AM
>To: Burcak Beser; Samita Chakrabarti; Wesley George
>Cc: Samita Chakrabarti; gabriel montenegro; [e-mail]
>Subject: RE: [16NG] WG last call on
draft-ietf-16ng-ipv4-over-802-dot-16-
>ipcs-02 + RE: regarding my comments on MTUs
>
>I would also support to prevent MTU limitations in the I-D, which would
>be easy based on L3 tunneling, e.g. GRE over IP (IP can fragment and
>reassemble the tunneled payload inside the access network). L2
tunneling
>is much more critical, because L2 technologies often miss the
>functionality to fragment and reassembly packets over a link. If L2
>breaks, there is no way to recover.
>
>Bye
>Max
>
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On Behalf Of
>ext Burcak Beser
>Sent: Tuesday, March 25, 2008 8:33 PM
>To: Samita Chakrabarti; 'Wesley George'
>Cc: 'Samita Chakrabarti'; 'gabriel montenegro'; [e-mail]
>Subject: Re: [16NG] WG last call on
>draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-02 + RE: regarding my
comments
>on MTUs
>
>As far as I can see we tree options:
>
>1. Get WiMAX Forum to handle 1500 byte packets. I am not sure how this
>may be achieved other than traveling back in time to impact NWG v1.
>
>2. Change this draft to 'personal'-ipv4-over-wimax-ipcs and use 1400
>byte limitation from WiMAX Forum NWG v1.
>
>3. Write the draft for IPCS  assuming L2 tunneling and no MTU
>limitations; and put the 1400 byte case on the appendix stating that
>WiMAX is expected to be the widest 802.16 deployment and NWG v1 has the
>1400 byte limitation as a special case, and offer the remedies and
state
>the problems.
>
>Personally I like the option 3 which is cleaner and straight forward.
>
>-burcak
>________________________________________
>From: Samita Chakrabarti [[e-mail]]
>Sent: Friday, March 21, 2008 4:07 PM
>To: 'Wesley George'; Burcak Beser
>Cc: 'gabriel montenegro'; 'Jari Arkko'; 'Samita Chakrabarti';
>[e-mail]
>Subject: RE: [16NG] WG last call on
>draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-02 + RE: [16NG] regarding my
>comments on MTUs
>
>Hi Wes,
>
>Please see in-line.
>
>>
>>Samita, your proposed update merely adds more words to say the
>>same thing that the current draft says - host MTU should be 1400. It's
>>helpful in that it adds more justification to your argument, but I
>still
>>disagree
>>with the underlying conclusion.
>>
>>My recommendation was to treat MTU as something that must be taken
into
>>consideration at the design phase of a WiMax network and the
>>initial configuration of the devices, not a hard and fast limit based
>on
>>the limitations and assumptions of ONE case out of many, especially
>since
>>the
>>806.16 over Ethernet draft completely contradicts your recommendation.
>It
>>views MTU as non-negotiable (must be at least 1500), and puts the
>>responsibility on the network operator to ensure that they've build
the
>>network to support the right underlying MTU or deal with the
>>fragmentation that will be inevitable.
>>I don't see why we wouldn't be doing the same thing here.
>[SC>]
>       As far as I know for IPCS network WiMAX forum has decided that
>their
>default link MTU would be 1400 bytes. Checkout RFC 5121 (appendix D)
>which
>chose the same value 1400 bytes for that reason. But one difference
from
>IPv6 case is that IPv6 specification requires to send RA with MTU
option
>if
>the MTU supported by the link is not the default value. Thus by
>following
>IETF specification WiMAX AR can send MTU option with 1400 value to the
>clients and the clients can adjust the MTU accordingly; while RFC 5121
>can
>specify 1500 bytes as the default MTU.
>
>Now IPV4CS would be happy to set the same default 1500 bytes following
>RFC5121 example - the only major issue is that there is no IPv4
>mandatory
>requirement from the server to communicate (through RA or DHCP option
>etc.)
>the non-default link MTU unless the client itself asks for it.
>
>The problem that Jari and others are pointing to is that if we specify
>1500
>bytes and the clients do not know that they are in WiMAX link and start
>sending packets over 1400 bytes, the packets will not be delivered at
>all.
>Those clients will not operate in the WiMAX network.
>
>Please note that WiMAX forum can change their default MTU value in the
>next
>revision, but the current specifications (Rls 1.1) cannot change.
>
>This is the data behind the decision on 1400 bytes as initial value; it
>matches the criteria that was given by Jari on the list. This IPv4CS
>recommends the new clients to request MTU option from DHCP requests for
>efficiency.
>
>If you or Burcak can work with WiMAX forum and produce a note from the
>chair
>that 1500byte  IPv4CS payload is OK for WiMAX network for the current
>NWG
>releases in the next one or two weeks, we can really appreciate that
and
>change to 1500 bytes. Currently, I do not know of any other deployment
>of
>IPv4CS other than WMF.
>
>
>
>>
>>Also, I do not understand how the statement
>>"The WiMAX forum [WMF] has specified the Max SDU size as 1522 octets."
>>aligns with the current statement in your draft
>>"The Length parameter of IEEE 802.16 MAC frame has a size of 11 bits.
>>Hence the total PDU size is 2048 bytes.  The IPv4 payload can be a
>>maximum value of 2038 bytes ( Total PDU size (2048) - (MAC Header (6)
+
>>CRC (4)), which is the maximum possible MTU."
>>
>>Where are those other ~500 octets going? Forgive my ignorance, but is
>>there some layer between SDU and PDU that has that sort of overhead,
or
>is
>>this another example of arbitrary limits that conflict with each
other?
>[SC>]
>      I do not know why WMF has specified 1522 bytes as MAX SDU and not
>beyond that. You need to ask that question to the WiMAX forum. For
>reference, please check RFC 5121 Appendix D.
>
>
>Thanks,
>-Samita
>
>
>
>
>
>>
>>On Thu, 20 Mar 2008, Burcak Beser wrote:
>>
>>> I have to admit that I fail to understand the reason for the MTU
>>limitation in the first place. The draft talks about Layer 2 tunnels
>>between BS and AR, and than GRE is being given as an example which
>causes
>>the problems in the first place. Instead of GRE, if 802.1Q VLANs are
to
>be
>>used this artificial limitation will not be taken into considereation.
>>>
>>> Is it possible to clarify the sentence "Hence if a IPv4CS MS is
>>configured for 1500 bytes it will have to be communicated by the
access
>>router(AR) about the default link MTU (1400 bytes) in WiMAX network."?
>Due
>>to fragmentation support in the 802.16 transport aribitrary PDU sizes
>are
>>supported even when the maximum SDU size is limited. In the light of
>>fragmentation the "The WiMAX forum [WMF] has specified the Max SDU
size
>as
>>1522 octets." only means that a 1600 byte PDU will be transmitted in
at
>>least two chunks. The 802.16 transport will carry almost anything that
>the
>>underlying native protocol can.
>>>
>>> The normative 'should' in the sentence "Therefore, IEEE 802.16 frame
>>SHOULD support for 1500 byte IP payload..." is unnecessary.
>>>
>>> The use of normative 'should' in ".. IPv4 and IPV4CS clients SHOULD
>>implement DHCP interface MTU option..." sentence looks like
>conditionally
>>mandating the use of DHCP as well. A clear requirement will be better.
>The
>>inclusion of IPv4 clients is first not correct since ARP would work,
>and
>>second is out of scope for this draft by definition.
>>>
>>> I understand that IPv4CS cannot transmit ARP messages but "An IPv4CS
>>client is not capable of doing ARP probing either to find out the link
>>MTU." looks like stating that "IPv4CS client MUST NOT use ARP
>messages". At
>>the same time IPv4CS client has to be defined.
>>>
>>> "Consequently, the clients are encouraged to run PMTU[RFC 1191]
>algorithm
>>or PPMTUD[RFC 4821] for appropriating the bandwidth usage over the
>route-
>>path or end-to-end transport layers. However, PMTU mechanism has
>inherent
>>problems of packet loss due to ICMP messages not reaching the sender
>and
>>IPv4 routers not fragmenting the packets due to DF bit being set in
the
>IP
>>packet." Can we state this sentence in normative manner?
>>>
>>> I have to admit that the draft struggles around the artificial MTU
>>limitation which is not justified, and omits other important subjects.
>>>
>>> -burcak
>>>
>>> -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]] On Behalf
>Of
>>Samita Chakrabarti
>>> Sent: Thursday, March 20, 2008 7:18 PM
>>> To: 'Wesley George'; 'gabriel montenegro'; 'Jari Arkko'
>>> Cc: 'Samita Chakrabarti'; [e-mail]
>>> Subject: Re: [16NG] regarding my comments on MTUs
>>>
>>> Hi Jari and Gabriel,
>>> Thanks for the guidelines on re-wording the text on MTU
determination
>for
>>IP4CS link. Thanks to Wes for your proposed text as well; I have taken
>some
>>ideas from your text.
>>>
>>>
>>> Here is the proposed text on MTU based on the wg discussion and the
>AD
>>> guideline:
>>> ------------------------------------
>>>
>>> 5. Maximum Transmission Unit considerations for IPv4CS link
>>>
>>> [RFC894] specifies 1500 bytes as a maximum length of IPv4 over
>Ethernet
>>and encourages to support full-length packets. Therefore, IEEE 802.16
>frame
>>SHOULD support for 1500 byte IP payload in the IPv4CS link by
>supporting
>>larger than 1500 bytes link MTU between the MS and the Access router
>(AR).
>>> The extra overhead that IEEE 802.16 frame should support in this
>case,
>>depends on the tunneling protocols or any other virtual or
>pseudo-wiring
>>protocols packet overhead.
>>>
>>>   The current architecture of IPv4CS in IEEE 802.16 networks is
>defined
>>in
>>>   the WiMAX (Worldwide Interoperability for Microwave Access) forum
>[WMF].
>>>   The addressing and operation of IPv4CS described in this document
>are
>>>   applicable to the WiMAX networks as well. The WiMAX forum [WMF]
has
>>>   specified the Max SDU size as 1522 octets. However, it is
>recommended
>>>   that IP-payload in WiMAX architecture [WMF] specified network is
>1400
>>>   bytes due to overhead of GRE tunnel and possible
>>>   additional over-head of different types of tunneling (such as
>IPSec/UDP
>>>   tunneling) between the base station (BS) and Access Router.
>>>
>>>   Hence  if a IPv4CS MS is configured for 1500 bytes it will have to
>be
>>>   communicated by the access router(AR) about the default link MTU
>(1400
>>>   bytes) in WiMAX network.
>>>   However, currently in IPv4 client architecture a node is not
>required
>>>   to ask for MTU option in its DHCP messages nor the
>>>   IPv4 router-advertisements
>>>   are required to advertise link MTU option when the link does not
>>support
>>>   1500 byte de-facto MTU size. An IPv4CS client is not capable of
>doing
>>ARP
>>>
>>>   probing either to find out the link MTU.
>>>   Thus current specifications of WiMAX network access routers cannot
>>>   communicate its link MTU to the IPV4CS MS. On the other hand, it
is
>>>   imperative for an MS to know the link MTU size if it is not the
>default
>>>   MTU value for de-facto standard in order to
>>>   successfully send packets in the network towards the first hop.
>>>   This document can not also assume that the legacy IPv4 client
>>>   implementation with IEEE 802.16 layer 2 support,
>>>   would be able to dynamically sense IPv4CS WiMAX network and adjust
>>>   their MTU size  accordingly.
>>>
>>>   Thus for IPv4CS over IEEE 802.16 the default MTU size is 1400
>bytes.
>>>
>>>   This document recommends that all future implementations of IPv4
>and
>>>   IPV4CS clients SHOULD implement DHCP interface MTU option
[RFC2132]
>in
>>>   order to configure its interface MTU according to the access
>network in
>>>   order to maximize the capacity of the bandwidth of
>>>   the network. Consequently, the clients are encouraged to run
>>>   PMTU[RFC 1191] algorithm or PPMTUD[RFC 4821] for
>>>   appropriating the bandwidth usage over the route-path or
end-to-end
>>>   transport layers. However, PMTU mechanism has inherent problems of
>>packet
>>>
>>>   loss due to ICMP messages not reaching the
>>>   sender and IPv4 routers not fragmenting the packets due to DF bit
>being
>>>   set in the IP packet. The above mentioned path MTU mechanisms will
>take
>>>   care of the MTU size between the MS and its correspondent node
>across
>>>   different flavors of convergence layers in the WiMAX networks,
>>>   IEEE 802.16 networks and other types of networks such as Wi-Fi,
>>>   Ethernet or 3G networks.
>>>
>>> --------------------------
>>>
>>> Review comments are welcome.
>>>
>>> Regards,
>>> -Samita
>>>
>>>> -----Original Message-----
>>>> From: [e-mail] [mailto:[e-mail]] On
Behalf
>Of
>>>> Wesley George
>>>> Sent: Thursday, March 20, 2008 8:24 AM
>>>> To: gabriel montenegro
>>>> Cc: Samita Chakrabarti; [e-mail]
>>>> Subject: Re: [16NG] regarding my comments on MTUs
>>>>
>>>> I have been thinking about the discussions regarding MTU, and would
>>>> like to propose some alternate language for section 5 of the ipcs
>>>> draft. I will caveat this by saying that it is my first attempt at
>an
>>>> ID (or a part of
>>>> one) but I thought that it might be helpful to propose an
>alternative
>>>> rather than simply saying that the language that is in the -02
draft
>>>> currently in Last Call that IMO is not adequate, due to its
conflict
>>>> with the .16 over ethernet draft.
>>>>
>>>> ** proposed draft language to replace the first paragraph of
section
>5
>>>> **
>>>>
>>>> When considering end host MTU, there are two points at which MTU
>must
>>>> be considered. First, the end to end path MTU between one IP host
>and
>>>> another. In 802.16, this is expected to follow existing convention
>[rfc
>>>> citation needed?] for fragmentation and path MTU discovery between
>end
>>>> hosts, and will not be treated here.
>>>>
>>>> The point at which MTU must be considered and will be treated by
>this
>>>> document is the path between the Base Station (BS) and the ASN
>Gateway
>>>> or HA, where traffic is usually encapsulated using one of several
>>>> methods before being allowed to transit the remaining path as
native
>IP
>>>> traffic.
>>>> On this portion of the path, there are two cases which must be
>>considered:
>>>>
>>>> 1) Where the underlying MTU of the transport mechanism between the
>BS
>>>> and the ASN GW or HA is configurable to a value > 1600 bytes or is
>>>> known to support the same
>>>> 2) Where the underlying MTU of the transport mechanism between the
>BS
>>>> and the ASN GW or HA is not a known value, or is not able to be
>>>> configured to MTU > 1600 bytes
>>>>
>>>> In case 1, the end host MTU SHOULD be set to at least 1500 bytes,
>but
>>>> can be set to any higher value supported by the underlying network
>up
>>>> to the maximum supported size on 802.16 of 2038 bytes.
>>>>
>>>> With an end host MTU of 1500 bytes or more, the underlying network
>MUST
>>>> support an MTU of at least 1500 bytes plus the overhead of the
>chosen
>>>> encapsulation method between the BS and the ASN GW or HA. For ease
>of
>>>> standardization, the underlying network SHOULD support an MTU of at
>>>> least 100 bytes larger than the chosen host MTU value, as this is
>large
>>>> enough to ensure that there is no dropping or fragmentation of
>oversize
>>>> packets regardless of the encapsulation method.
>>>>
>>>> In case 2, the end host MTU SHOULD be set to 1400 bytes to ensure
>that
>>>> there is no dropping or fragmentation of oversize packets
regardless
>of
>>>> the encapsulation method. If the end host MTU is set higher, or the
>MTU
>>>> of the underlying transport network is lower than 1500 bytes, the
>>>> network MUST be able to accept any fragmentation of packets larger
>than
>>>> the supported transport MTU, or MUST employ a method of MTU
>discovery
>>>> to prevent oversize packets from being generated by the end host.
>>>>
>>>> In order to preserve the defacto standard of MTU 1500 bytes for end
>>>> host use, case 1 SHOULD be followed if at all possible. If adhering
>to
>>>> case 1 is not possible, case 2 is presented as an alternative.
>>>>
>>>> ** end proposed draft language **
>>>>
>>>> The second paragraph of section 5 can remain as-is.
>>>>
>>>> Some additional comments:
>>>> It may be a good idea to add in language from the background slides
>>>> that were presented in Philadelphia which identify why 100 bytes is
>the
>>>> recommended padding between host MTU andNetwork MTU for further
>>>> clarification.
>>>>
>>>> I concede that it's not really feasible to rely on an MTU discovery
>>>> method to compensate for MTU on the transport network that is not
>>>> capable of supporting the full 1500 bytes of host MTU. However, I
>think
>>>> that the proposed language provides ways to work this based on
>whether
>>>> that is a known value or not (via the two different cases) and
>>>> addresses that concern. I think that this is much closer in idea
>with
>>>> the way that the EthernetCS draft is written, treating 1500 as the
>>>> defacto standard that we should prefer, but covering what the
>reasoning
>>>> is for MTU settings and identifying ways to compensate for
>limitations
>>>> in the underlying transport network, rather than simply assuming
>that
>>>> those limitations exist and catering to the lowest common
>denominator.
>>>>
>>>> Thanks,
>>>> Wes
>>>>
>>>> _________________________________________
>>>>   Wesley George
>>>>       Sprint IP Engineering
>>>>   703-689-7505 (O)  703-864-4902 (PCS)
>>>>         http://www.sprint.net
>>>> _________________________________________
>>>>
>>>>
>>>> On Tue, 18 Mar 2008, gabriel montenegro wrote:
>>>>
>>>>> For the IPv4 case, I have no problem with the MTU staying at 1400
>>>>> bytes
>>>> per the current draft.
>>>>> There is no sure-fire way to indicate to the MS what the MTU is.
>The
>>>> draft currently says:
>>>>>
>>>>>   The MTU value of the MS can be configured via Path MTU Discovery
>[6],
>>>>>   Packetization layer path MTU discovery [7], DHCP MTU option [8]
>or
>>>>>   static configuration of each MS.As pointed out by Jari, what
>we're
>>>> talking about is the *interface* MTU, not the *path* MTU
>>>>> (minimum hop MTU of all the hops in a path). Accordingly, when
>>>>> applying
>>>> [6] or [7]
>>>>> to discover the interface MTU, they must be used between the MS
and
>>>>> its
>>>> immediate IP hop,
>>>>> the access router. Of course, in order to use [6] or [7], some
>>>>> interface
>>>> MTU must be assumed
>>>>> to begin the discovery process.
>>>>>
>>>>> 1400 is a very reasonable value for this initial default MTU.
Given
>>>>> the
>>>> well-known issues with PMTU,
>>>>> and the scant support for the DHCP Interface MTU option, 1400 will
>>>>> work
>>>> well in the absence of
>>>>> any further MTU discovery or configuration. It will also avoid
>>>> fragmentation in what is expected
>>>>> to be the most common deployment for 802.16: WiMAX networks. 1500
>>>>> bytes,
>>>> the other MTU value
>>>>> folks have proposed for IPv4 CS does not have this virtue and will
>>>>> incur
>>>> fragmentation.
>>>>>
>>>>> Notice that for DHCP we should really say "Interface MTU option"
>>>>> to clarify that we're talking about option 26 (Section 5.1,
>RFC2132).
>>>>>
>>>>> Going forward we may have a more reliable and less time consuming
>>>> mechanism to
>>>>> derive the interface IP MTU by learning the layer 2 maximum SDU
via
>a
>>>>> new
>>>> TLV in the SBC exchange
>>>>> in 802.16. This is being proposed  this week at the Orlando IEEE
>>meeting.
>>>>>
>>>>> As for the ethernet CS MTU, as Max said during his presentation
>last
>>> week,
>>>> there is no choice. We must
>>>>> preserve the ethernet MTU as expected from "Ethernet" CS,
>regardless
>>>>> of
>>>> the fact that 1500 byte IP packets will incur
>>>>> fragmentation in common WiMAX networks.
>>>>>
>>>>>
>>>>> -gabriel
>>>>>
>>>>>
>>>>> ----- Original Message ----
>>>>> From: Jari Arkko <[e-mail]>
>>>>> To: [e-mail]
>>>>> Sent: Thursday, March 13, 2008 1:18:55 PM
>>>>> Subject: [16NG] regarding my comments on MTUs
>>>>>
>>>>>
>>>>> As a clarification of my comments during the WG meeting I would
>like
>>>>> to state the following:
>>>>>
>>>>>> From AD perspective the WG is free to decide whatever MTU value
>that
>>>>>> you
>>>>> wish to have, as long as you are both aware of and document the
>>>>> implications of this choice. Some of the implications include:
>>>>>
>>>>> - difficulty of manual configuration
>>>>> - ability to raise/lower the values automatically
>>>>> - capability of 802.16 backhaul networks to handle larger MTUs
>(ipcs,
>>>>> ethcs, wimax and non-wimax)
>>>>> - ability or inability to determine what network you are in
>>>>> - inability of L2 devices to send ICMP messages
>>>>>
>>>>> Hope this clarifies,
>>>>>
>>>>> Jari
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 16NG mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/16ng
>>>>>
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> 16NG mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/16ng
>>>
>>>
>>>
>>> _______________________________________________
>>> 16NG mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/16ng
>>>
>>>
>>>
>
>
>
>
>_______________________________________________
>16NG mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/16ng



_______________________________________________
16NG mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/16ng