Subject: Re: [16NG] regarding my comments on MTUs

From: gabriel montenegro <[email-masked]>
Date: Tue, 18 Mar 2008 12:17:35 -0700 (PDT)

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 <[email-masked]>
To: [email-masked]
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
[email-masked]
https://www.ietf.org/mailman/listinfo/16ng

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

---

From: Wesley George <[email-masked]>
Date: Thu, 20 Mar 2008 11:24:18 -0400 (EDT)

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
_________________________________________

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Thu, 20 Mar 2008 19:17:48 -0700

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: [email-masked] [mailto:[email-masked]] On Behalf Of
>Wesley George
>Sent: Thursday, March 20, 2008 8:24 AM
>To: gabriel montenegro
>Cc: Samita Chakrabarti; [email-masked]
>Subject: Re: [16NG] regarding my comments on MTUs
>
>>   static configuration of each MS.As pointed out by Jari, what we're
>talking about is the *interface* MTU, not the *path* MTU
>> 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

---

From: Burcak Beser <[email-masked]>
Date: Thu, 20 Mar 2008 21:14:52 -0700

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?

Also within the draft "IPv4 over IEEE 802.16's IP CS" section 6 it is metioned that "each MS shall be on different IP subnet", does this mean that the DHCP subnet returned has to be 255.255.255.255? If so why? I do not see the reason for ech MS being at a different subnet. I understand that each MS is within the smallest broadcast domain possible. I am sure that each MS belonging a different subnet will have unintended consequences within the network. By the statement of Appendix A it looks like that every MS will need a default gateway address. I do not understand the benefit of such a hidden requirement.

I assume the sentence "DHCP [4] SHOULD be used for assigning IPv4 address for the MSs." will be removed.

Is there a hidden normative requirement on AR having a DHCP server in the sentence "In case DHCP server does not reside in AR, the AR SHOULD implement DHCP relay Agent [5]." ?

I would like a stronger wording for the sentence "In a point-to-point link model, address resolution may not be needed." This is the basis of IPv4CS.

For the sentence "IPv4 multicast packets are carried over the point-to-point link between the AR and the MS (via the BS)."; it is my understanding that multicast CIDs can carry IP packets to multiple MS'. The sentence must be removed. The following sentence is one of the methods for supporting multicast, and at least multicast CIDs method must be explained as well. Even for the multi-unicast multicast case, a standards based AR will not work.

As nit-picking point the reference 12 is a zip file that contains 12 documents. It will be better if these are stated individually.

Second nit-pick; sentence "all the packets originated at.." must start with capital A.

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: [email-masked] [mailto:[email-masked]] On Behalf Of Samita Chakrabarti
Sent: Thursday, March 20, 2008 7:18 PM
To: 'Wesley George'; 'gabriel montenegro'; 'Jari Arkko'
Cc: 'Samita Chakrabarti'; [email-masked]
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.

 [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.

Regards,
-Samita

>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
>currently in Last Call that IMO is not adequate, due to its conflict
>with the .16 over ethernet draft.
>
>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
>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.
>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
>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.
>
>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.
>
>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
>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
>
>> For the IPv4 case, I have no problem with the MTU staying at 1400
>> bytes
>per the current draft.
>> (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
>> 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
>> 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.
>>
>> derive the interface IP MTU by learning the layer 2 maximum SDU via a
>> new
>TLV in the SBC exchange
week,
>> As a clarification of my comments during the WG meeting I would like
>> to state the following:
>>

---

From: Wesley George <[email-masked]>
Date: Fri, 21 Mar 2008 12:23:21 -0400 (EDT)

I agree with the comments from Burcak below.

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.

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?

Thanks,
Wes

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Fri, 21 Mar 2008 16:07:18 -0700

Hi Wes,

Please see in-line.

>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.

>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

>> 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
>>
>Samita Chakrabarti
>> [RFC894] specifies 1500 bytes as a maximum length of IPv4 over Ethernet
>and encourages to support full-length packets. Therefore, IEEE 802.16 frame

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Fri, 21 Mar 2008 17:02:49 -0700

Hi Burcak,

Thanks for the review. I have already replied the MTU issue on a separate
email. Please see in-line for the rest.

>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
[SC>] 

       Please check RFC 5121 (appendix D.) on WMF Max SDU size.
 
>
>The normative 'should' in the sentence "Therefore, IEEE 802.16 frame SHOULD
>support for 1500 byte IP payload..." is unnecessary.
>
[SC>] 
      Are you recommending MUST instead of SHOULD?

>
>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.
[SC>] 
[SC>]  IPV4CS document does not allow ARP for IPv4CS client; see section 7.

>packet." Can we state this sentence in normative manner?
[SC>]  
      We can put SHOULD here.
>
>Also within the draft "IPv4 over IEEE 802.16's IP CS" section 6 it is
>metioned that "each MS shall be on different IP subnet", does this mean
>that the DHCP subnet returned has to be 255.255.255.255? If so why? I do
>not see the reason for ech MS being at a different subnet. I understand
>that each MS is within the smallest broadcast domain possible. I am sure
>that each MS belonging a different subnet will have unintended consequences
>within the network. By the statement of Appendix A it looks like that every
>MS will need a default gateway address. I do not understand the benefit of
>such a hidden requirement.
[SC>] 
     The link between MS and AR is a point to point link. So there is no
other node on the same link. The concept of subnet of multiple nodes do not
apply here. 

We will update the draft with more info on what IPv4CS link means between MS
and AR.

>Is there a hidden normative requirement on AR having a DHCP server in the
>sentence "In case DHCP server does not reside in AR, the AR SHOULD
>implement DHCP relay Agent [5]." ?
[SC>]  No requirement that AR must contain DHCP server. But the requirement
is that AR is the main gateway node which assigns/relays the local address.
I understand that for CMIP (client MIP) case, the address is the
home-address. We can clarify that.

>
>I would like a stronger wording for the sentence "In a point-to-point link
>model, address resolution may not be needed." This is the basis of IPv4CS.
[SC>] Ok.

>
>For the sentence "IPv4 multicast packets are carried over the point-to-
>point link between the AR and the MS (via the BS)."; it is my understanding
>that multicast CIDs can carry IP packets to multiple MS'. The sentence must
>be removed. The following sentence is one of the methods for supporting
>multicast, and at least multicast CIDs method must be explained as well.
>Even for the multi-unicast multicast case, a standards based AR will not
>work.
>
[SC>]  As far as IP layer is concerned, it sees  one point-to-point
Link between the MS and AR. Multicast CIDs are L2 concepts, IP layer does
not know about them. Will clarify this point.

>As nit-picking point the reference 12 is a zip file that contains 12
>documents. It will be better if these are stated individually.
[SC>] 
[SC>]  We will follow what RFC 5121 has done.

>limitation which is not justified, and omits other important subjects.

[SC>] Thanks for the review. I have noticed that this draft needs more flesh
on clarification like its counter parts in IPv6. We will make those
editorial fixes based on several comments received on this list.

Regards,
-Samita

---

From: Burcak Beser <[email-masked]>
Date: Tue, 25 Mar 2008 12:33:15 -0700

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 [[email-masked]]
Sent: Friday, March 21, 2008 4:07 PM
To: 'Wesley George'; Burcak Beser
Cc: 'gabriel montenegro'; 'Jari Arkko'; 'Samita Chakrabarti'; [email-masked]
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.

[SC>]

[SC>]

Thanks,
-Samita

---

From: Wesley George <[email-masked]>
Date: Wed, 26 Mar 2008 12:25:44 -0400 (EDT)

I also like option 3. My interest in this draft has always been from the 
perspective of providing different solutions to known cases and 
identifying gotchas and caveats to those cases, not mandating a certain 
solution based on one case that we must later revisit with the inertia of 
"it already exists this way today and I'm not changing it" to counteract.

I do think that this issue needs to be taken up in subsequent interaction 
with the wimax forum, but I am not involved in that forum, so is there 
someone else that can raise this concern?

Thanks,
Wes

---

From: "Riegel, Maximilian (NSN - DE/Muenich)" <[email-masked]>
Date: Thu, 27 Mar 2008 18:17:06 +0100

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: [email-masked] [mailto:[email-masked]] On Behalf Of
ext Burcak Beser
Sent: Tuesday, March 25, 2008 8:33 PM
To: Samita Chakrabarti; 'Wesley George'
Cc: 'Samita Chakrabarti'; 'gabriel montenegro'; [email-masked]
Subject: Re: [16NG] WG last call on
draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-02 + RE: regarding my comments
on MTUs

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.

-burcak
________________________________________
From: Samita Chakrabarti [[email-masked]]
Sent: Friday, March 21, 2008 4:07 PM
To: 'Wesley George'; Burcak Beser
Cc: 'gabriel montenegro'; 'Jari Arkko'; 'Samita Chakrabarti';
[email-masked]
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.

>helpful in that it adds more justification to your argument, but I
still
>disagree
>the limitations and assumptions of ONE case out of many, especially
since
>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.

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.

[SC>]

Thanks,
-Samita

>>   The current architecture of IPv4CS in IEEE 802.16 networks is
defined
>in
>>   1500 byte de-facto MTU size. An IPv4CS client is not capable of
doing
>ARP
>>> ** proposed draft language to replace the first paragraph of section
5
>>> **
and
>>> document is the path between the Base Station (BS) and the ASN
Gateway
>>>> There is no sure-fire way to indicate to the MS what the MTU is.
The
>>> draft currently says:
>>>> preserve the ethernet MTU as expected from "Ethernet" CS,
regardless
>>>> of
>>>>> From AD perspective the WG is free to decide whatever MTU value
that
>>>>> you