Re: [16NG] regarding my comments on MTUs

[Wesley George <[e-mail]>]

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