Subject: Re: [16NG] Comments on Transmission of IPv4 packets over IEEE 802.16's IP CS draft

From: gabriel montenegro <[email-masked]>
Date: Mon, 25 Feb 2008 08:38:06 -0800 (PST)

Some comments inline...

----- Original Message ----
From: "[email-masked]" <[email-masked]>
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Sent: Monday, February 25, 2008 12:26:47 AM
Subject: [16NG] Comments on Transmission of IPv4 packets over IEEE 802.16's IP CS draft

 

Hi,

Please find some of my 
comments/clarification sought on the draft.

-------------

1. Section 1: 

  This document 
specifies a method for encapsulating and transmitting
   IPv4 [2] 
and Address Resolution Protocol (ARP) packets over IP CS of
   IEEE 
802.16. 

Comment:

The document does talk about encapsulation of IPv4 packets but not of ARP 
packets.

     Is 
something missing?

gab> This is taken out in the more recent version under preparation.

2. Section 
3:

  At least one L2 
tunnel is required for each MS, so that IP packets can
   be sent 
to MSs before they acquire IP addresses.

Comment:

    My 
understanding is that "atleast" signify if the MS has more than one service 
flows , there

    will be 
seperate tunnels with different CIDs for a single MS.

    Can the 
sentence be rephrased to indicate this.

gab> authors, please take note.

3. Section 
3:

    The 
diagram does not support the statement that there will be multiple L2 Tunnel. 

    Multiple 
L2 tunnels should be shown carrying CID1....CIDn

gab> no need to show it in the diagram if it is mentioned as a possibility in the text, but authors please take note and
decide

4. Section 
5:

    Comment:

    The 
rational behind MTU being 1440 is not provided. Its mentioned that it should 
be

less than 1500, but not why it should be 1440 and not 1430?

The correct rational to reach 1440 shall be provided or some reference to be 
given

gab> more text in this section is being worked into the new version

5. Section 
6:

     In 
case DHCP server does not reside in AR, the
    AR SHOULD 
implement DHCP relay Agent [6].

    Comment:
    AR can 
also implement a DHCP Proxy.

    The 
statement should read

    "In case 
DHCP server does not reside in AR, the
    AR SHOULD implement 
DHCP relay Agent /DHCP Proxy"

    The 
reference is also incorrect. It should be [5] instead of [6]

gab> Authors, please take note. BTW, the latest version has removed any mention of DHCP proxy
as there is no such thing defined in any IETF RFC.

regards,

Keshav

-----Inline Attachment Follows-----

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

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

---

From: "Syam Madanapalli" <[email-masked]>
Date: Mon, 25 Feb 2008 22:32:38 +0530

>
>
> Hi,
>
> Please find some of my comments/clarification sought on the draft.
>
> -------------
> 1. Section 1:
>
>   This document specifies a method for encapsulating and transmitting
>    IPv4 [2] and Address Resolution Protocol (ARP) packets over IP CS of
>    IEEE 802.16.
>
>   Comment:
>      The document does talk about encapsulation of IPv4 packets but not of
> ARP packets.
>      Is something missing?
>
> 2. Section 3:
>   At least one L2 tunnel is required for each MS, so that IP packets can
>    be sent to MSs before they acquire IP addresses.
>
>   Comment:
>     My understanding is that "atleast" signify if the MS has more than one
> service flows , there
>     will be seperate tunnels with different CIDs for a single MS.
>     Can the sentence be rephrased to indicate this.
>

There can be a single tunnel between BS and AR, that's why draft recommends
at least one tunnel oer MS, and is nothing to do with service flows.  I think
the text is fine.

>
> 3. Section 3:
>
>     The diagram does not support the statement that there will be multiple
> L2 Tunnel.
>     Multiple L2 tunnels should be shown carrying CID1....CIDn
>
> gab> no need to show it in the diagram if it is mentioned as a possibility
> in the text, but authors please take note and
> decide
>

The current diagram is fine.

Thanks,
Syam

>
> 4. Section 5:
>
>     Comment:
>     The rational behind MTU being 1440 is not provided. Its mentioned that
> it should be
>      The correct rational to reach 1440 shall be provided or some reference
> to be given
>
> 5. Section 6:
>      In case DHCP server does not reside in AR, the
>     AR SHOULD implement DHCP relay Agent [6].
>     Comment:
>     AR can also implement a DHCP Proxy.
>     The statement should read
>     "In case DHCP server does not reside in AR, the
>     AR SHOULD implement DHCP relay Agent /DHCP Proxy"
>
>     The reference is also incorrect. It should be [5] instead of [6]
>

---

From: Wesley George <[email-masked]>
Date: Tue, 26 Feb 2008 09:41:01 -0500 (EST)

Regarding:

> it should be less than 1500, but not why it should be 1440 and not 
> 1430?
>

I agree with the comments above that more explanation is needed, but I 
fear that I disagree with the underlying rationale that will be added, and 
I thought I'd get some discussion started on it in the hope of 
incorporating that into the new draft.

While I realize that the MTU 1400 is a recommendation, not a requirement, 
I don't see why we would make a recommendation that seems to be assuming a 
very low MTU value (1500) on the underlying transport network, as this 
could be a significant limiting factor as we move forward.
Consider that both the GE and 10GE standards have provisions for frame 
size larger than 1500, specifically because this starts to be a limiting 
factor for throughput as speeds increase. Better for us to be 
forward-thinking now than to have to go back later to fix it.

I think it would be better for this section to discuss the maximum 
SUPPORTABLE MTU based on the 802.16 standard (whatever the largest PDU 
the air interface could support - it's unclear to me from reading the .16 
standard). The section should then discuss what items need to be 
accounted for when setting the MTU for IP CS, such as the GRE encap and 
the air MAC overheads, as well as the MTU limits of the underlying 
transport media. Then, it should recommend the configuration of the max 
MTU that is supportable under those circumstances, to be no less than X, 
with X probably =1400. In other words, 1400 is the MINIMUM, not the maximum.
It's better to have the system support a larger MTU and let PMTUD throttle 
it back than to start at such a small MTU only to have it possibly made 
even smaller.

I agree that on low-speed interfaces, a high MTU creates problems if you 
are mixing small, delay-sensitive packets with larger ones due to 
serialization delays, but as 802.16 evolves, I think that the speeds 
are/will be high enough that this is less of a concern. If it does 
become an issue, it's conceivable to use things like LFI over PPP 
(rfc1990) to mitigate the problem. So perhaps a small discussion about 
serialization delay and possible solutions would be advisable as well.

It's probably a philosophical debate in some way - whether the network 
should adapt to the needs of the protocol or vice versa. However, my view 
is that  this recommendation as it currently stands is a bit of a circular 
argument:
a) we recommend an MTU of 1400 because the underlying network likely will 
have MTU of 1500 and we have to be able to compensate for overhead 
without fragmentation.
but...
b) there's no reason to design a network for transporting 802.16 data that 
has MTU > 1500 because the standard says that we only need 1400 + overhead.

I think that it's much easier to increase the MTU of the tranport 
mechanism assuming you take this into account during network 
implementation - eg use GE instead of FE as your transport so that you 
can do jumbo-frame. If the requirement is for only 1500, implementors 
might use Fast Ethernet, and then we're stuck with it until such time 
that 100Mbps isn't enough bandwidth. GE is getting cheap - PCs and SOHO 
routers have 10/100/1000 ports now, so I don't think that this would 
significantly add to the costs of implementation.

Consider one of the primary uses for a wireless card in a laptop - so you 
can access your company VPN and do work in the park or on the train. 
That tunnel would further reduce the MTU available for applications. While 
most applications can compensate for the fact that they may be 
encapsulated in a tunnel that reduces their MTU to 1500 minus tunnel OH, 
performance may start to suffer if there are multiple layers of overhead 
further reducing user MTU.

I think that even if we don't do as I've recommended above and discuss 
this from a max supportable MTU, we should at least be recommending 
that the network SHOULD be designed to support a minimum user MTU of 1500 
to keep it roughly standardized with things like Ethernet.
This would mean that the MTU on the infrastructure would need to be 1500+GRE on 
the transport network, and 1500 + air MAC on the air interface.

Thanks,

Wes George

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Tue, 26 Feb 2008 11:21:20 -0800

Hi Wes,

It is a good discussion on MTU. I agree that network bandwidth is increasing
and MTU should be large to avoid fragmentation and increase network
performance. But we still have to make sure that our immediate network needs
are met and the new specifications are not too painful for existing devices
and applications. Please see below about some reasons behind choosing
1400-byte default MTU. Some of us debated on the default MTU value for a
while off-line before choosing this value.

>the transport network, and 1500 + air MAC on the air interface.
[SC>] The draft says 802.16 network allows about 2038 bytes of IP payload.
So it is the maximum allowable MTU size for IPCS. The default value for MTU
chosen by WiMax forum is 1400 bytes for IP4 and IPv6. The IP4CS document is
immediately needed for the Wimax deployment. This accounts for 1500 - (GRE+
other overhead such as IPSec VPN with UDP that might be used in some SDOs).
Another goal of choosing this MTU is to avoid fragmentation when the data
packets flow across Wimax and other technologies such as 3G-data services
over Ethernet/Wi-fi. 
 Wimax network's default MTU must be <1500 bytes.  If we choose the default
MTU to be 1500, then Wimax network would have to somehow communicate (DHCP
option) to the client that the MTU for the link would be some 1400+ value.
However, currently there is no specified mechanism that the clients must
always ask for MTU option in DHCP request, thus it requires change in the
specification to make the client to be intelligent to sense that it is in a
Wimax network and now it should change its default MTU from 1500 to whatever
it supports.  So, thinking about the deployment need and backward
compatibility, we decided on 1400 bytes as default MTU for IP4CS. However,
the draft mentions clearly that this MTU can be changed by requesting DHCP
option or doing PMTU or using packetization layer PMTU on top of link MTU
determination. 

In order to make use of higher bandwidth network (such as 100 GE), perhaps
we can ensure that the new clients would be intelligent enough to ask for
link MTU  through the DHCP service or some other means. This will avoid
backward in-compatibility problems with old-implementations/devices.

Hope this explanation helps.

-Samita

---

From: Wesley George <[email-masked]>
Date: Wed, 27 Feb 2008 11:41:53 -0500 (EST)

Samita, thanks for your response. Some comments inline below.

> other overhead such as IPSec VPN with UDP that might be used in some SDOs).

so we should be starting with 2038 - GRE&other overhead rather than 
1500, with comments regarding what this means if your transport layer MTU 
is < 1500.

> packets flow across Wimax and other technologies such as 3G-data services
This goes exactly to what I said - you have a circular argument. Yes there 
are situations that the underlying network will not be able to support 
>1500 MTU, but you should treat this as a separate class with 
recommendations accordingly (probably 1400), not lower the default to 
cater to the lowest common denominator.
By the logic you're using right now, we should probably lower it even 
further, in case someone is using DSL or other PPPoX implementations (or 
even classical ATM) as their backhaul, since all of those have recommended 
MTU values in the 1400s.
My view is that this draft should acknowledge that this network issue can 
exist (the "your mileage may vary" clause) while still recommending the 
larger MTU wherever possible. That way clean-sheet designs implementing 
this will use a larger MTU to start with, and the necessary 
recommendations are in place for designs that must use some existing 
mechanism that can't support the primary recommendation.

> option or doing PMTU or using packetization layer PMTU on top of link MTU
Yes, I saw in the draft that it can be changed.
So why wouldn't we recommend that those options (specifically MTUD) be 
enabled by default at the appropriate locations, to handle the situations 
where default MTU is too *large* rather than to force those of us who 
realize that 1500 is what to shoot for to hope that DHCP or PMTUD will 
figure out that we support a larger than default MTU?

I assume that this isn't an end-to-end problem, because an end device 
that is not doing PMTUD at all would have lots of problems if it tries 
to talk to any host that is behind something with an MTU of < 1400 with 
DF turned on. 
Therefore this is only a problem across the backhaul from the air 
interface through the encapsulation to the point where data is 
decapsulated and routed as native IP. My thought is that all that is 
really necessary is for the encapsulating device to have the appropriate 
MTU set on its tunnel interface based on the MTU of the transport network 
- encap overhead. That way, it knows to respond to packets it receives 
from end hosts with the appropriate packet too big message to incite the 
end host to reduce its packet size.

> backward in-compatibility problems with old-implementations/devices.

Why couldn't that be covered as a recommendation in this draft? I think we 
all know that the longer we wait, the more deployments start happening, 
and they all contribute to the inevitable inertia that resists change, no 
matter how much sense it makes.

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

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Fri, 29 Feb 2008 14:36:42 -0800

Hi Wes,

Your points are noted on default MTU being 1500 for IPv4CS and recommending
the following for new-clients while old clients suffer fragmentation.

We have debated on the IPCS MTU size for a while, but we can request and
work with Wimax folks at IETF to see what the best way to lay out the MTU
message in the IPCS document. 

Thanks for your input.
-Samita