Subject: [16ng] Re: I-D ACTION:draft-ietf-16ng-ipv6-over-ipv6cs-02.txt

From: gabriel montenegro <[email-masked]>
Date: Wed, 6 Dec 2006 17:06:23 -0800 (PST)

I've added some comments (marked as [GM#]) and edits (please use diff).

-gabriel
_______________________________________________
16ng mailing list
[email-masked]
http://eeca16.sogang.ac.kr/mailman/listinfo/16ng

---

From: Basavaraj Patil <[email-masked]>
Date: Fri, 15 Dec 2006 16:11:40 -0600

Gabriel,

Addressing your comments in rev 3 (which has been submitted to the I-D
editor and should show
up soon) of the I-D:

>GM1]This, including service specific part,  is done by 802.16 (d and
>e). Immediately after ranging the MS and BS exchange their capability
>negotiation via REG-REQ and REG-RSP. These management frames negotiate
>parameters such as IP version and Convergence Sublayer support.

Modified text:
"It should be noted that immediately after ranging (802.16 air
interface procedure), the MS and BS exchange their capability
negotiation via REG-REQ and REG-RSP. These management frames negotiate
parameters such as IP version and Convergence Sublayer
support. Additionally during the establishment of the transport
connection for transporting IPv6 packets, the DSA-REQ and DSA-RSP
messages between the BS and MS indicate via the CS-Specification TLV
the CS that the connection being setup shall use. "

I believe this also addresses Jari's concern about the negotiation of
which CS is in use for a transport connection.

>[GM2]The WiMAX sections are not normative. Please move them to an appendix.

Done.

>[GM3]Informative text: please move to an appendix.
>[GM4]Informative text: please move to an appendix.

Done.

>[GM5]What is this? Perhaps just spell out as header or add to
> terminology

Changed HDR to header

>[GM6]This does not seem to be defined either. Define if it is not yet
> done. 

Expanded the acronym PDU -> Protocol Data Unit. I dont think I need to
define what a PDU is since it is a fairly standard OSI term.

>[GM7]This should be the one place where the default MTU is set
>(whatever the proper value ends up being).

Text added: The default MTU for IPv6 over 802.16
SHOULD be the same as specified in RFC2460 which is 1500 octets.

>[GM8]Informative text: please move to an appendix.

Done.

>[GM9]Why have a different MTU? This document should define the MTU
>over this link layer (IPv6 CS), and all applications should adhere
>to that. It would be best not to rely on RA MTU options in order to
>avoid interoperability issues.  The wimax document should not need
>this section at all.

The reason for a different default MTU in WiMAX is because of the Max
SDU size specified by WMF and this is normative. Additionally the fact
that there is a GRE tunnel between the BS and AR needs to be taken
into consideration as well. So the default recommendation of 1400
octets is good. The RA option is just to ensure that the standard IPv6
methods for MTU are considered.

>[GM10]Spell out.

Done.
CPE (Customer Premise Equipment).

>[GM11]Just say Per RFC 2461.
>[GM12]Just say: Per RFC 2461.

Done.

>[GM13]In both of these, this document is changing the limits with
>respect to 2461 and 2461-bis. Better check with Jari, but I thought
>this was discouraged.

I discussed this with Jari and this was also debated as part of the
2461bis IETF LC. It was agreed that IPv6 over foo docs can change the
limits. And hence this proposal. I have also checked with Hesham
S. (Ed of 2461bis) and verified if the proposal is okay.
So no change to the I-D.

>[GM14]These are informative.
>[GM15]These are informative.

Done.

>[GM16]Move to normative. Also, change the reference to 802.16 as specs
>here include not just 16e but also 16d (there may be others).

As per Jari's suggestion, we decided to not refer to FRD as that will
delay the publication of this document.
Changed all references to 802.16 (instead of d or e)

-Raj

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 16 Dec 2006 18:09:09 +0100

Basavaraj Patil wrote:
[...]
> SHOULD be the same as specified in RFC2460 which is 1500 octets.

Well, rfc2460 says it should be 1280, and on some links where MTU is 
configurable (ppp is given as an example) it should be 1500.

2460:
>    Links that have a configurable MTU (for example, PPP links [RFC-
>    1661]) must be configured to have an MTU of at least 1280 octets; it
>    is recommended that they be configured with an MTU of 1500 octets or
>    greater, to accommodate possible encapsulations (i.e., tunneling)
>    without incurring IPv6-layer fragmentation.

The goal of IP stack setting a correct MTU is that the underlying 
link-layer doesn't send it back a 'too big' message.  802.16 has a means 
to require length of SDU (packets) per service flow.  The 802.16 MAC 
header seems to allow for lengths up to 2^11 (len is encoded on 11 
bits).  So I think the IP stack could put packets as big as 2048 (2^11) 
on the 802.16 MAC, not necessarily 1500.

So I think a better text would be:

"The default MTU for IPv6 over 802.16 IPCS SHOULD be the same as 
specified in rfc2460, that is 1280.  If the 802.16 IPCS can set up 
service flows for larger MTUs then the MTU should be 2048, the maximum 
allowed by the 802.16 MAC header".

What do you think?

Alex

---

From: Basavaraj Patil <[email-masked]>
Date: Mon, 18 Dec 2006 10:33:52 -0600

Alex,

> configurable (ppp is given as an example) it should be 1500.

RFC 2460 says: " IPv6 requires that every link in the internet have an MTU
of 1280 octets or greater."

It is the minimum value that MUSt be supported by the links for IPv6. And as
you have quoted below, the 802.16 link can be considered to be a type of
link which supports a configurable MTU. The 1280 octet value is mandatory. I
do not even need to mention it. What is being recommended for the link which
has a configurable MTU in this I-D is 1500 octets.

> on the 802.16 MAC, not necessarily 1500.

True. And I have explained this in the I-D. But generally you would have
links in the network which have support 1500 byte or less packets. So
sending packets on the .16 link >1500 bytes would result in requiring
fragmentation. So the recommendation for 1500 makes sense.

> allowed by the 802.16 MAC header".\
> 
> What do you think?

No... As I explained above, there are issues if you send packets > 1500
bytes. Just because one link in the network is able to support large packets
is not enough. You have to consider the backhaul capability as well.

-Raj

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 18 Dec 2006 18:20:31 +0100

Basavaraj Patil wrote:
>> Basavaraj Patil wrote: [...]
>>> Text added: The default MTU for IPv6 over 802.16 SHOULD be the 
>>> same as specified in RFC2460 which is 1500 octets.
>> Well, rfc2460 says it should be 1280, and on some links where MTU 
>> is configurable (ppp is given as an example) it should be 1500.
> 
> RFC 2460 says: " IPv6 requires that every link in the internet have 
> an MTU of 1280 octets or greater."
> 
> It is the minimum value that MUSt be supported by the links for IPv6.
>  And as you have quoted below, the 802.16 link can be considered to 
> be a type of link which supports a configurable MTU. The 1280 octet 
> value is mandatory. I do not even need to mention it. What is being 
> recommended for the link which has a configurable MTU in this I-D is
>  1500 octets.

Why 1500?

>>> 1661]) must be configured to have an MTU of at least 1280 octets;
>>> it is recommended that they be configured with an MTU of 1500
>>> octets or greater, to accommodate possible encapsulations (i.e.,
>>> tunneling) without incurring IPv6-layer fragmentation.
>> link-layer doesn't send it back a 'too big' message.  802.16 has a
>>  means to require length of SDU (packets) per service flow.  The 
>> 802.16 MAC header seems to allow for lengths up to 2^11 (len is 
>> encoded on 11 bits).  So I think the IP stack could put packets as
>>  big as 2048 (2^11) on the 802.16 MAC, not necessarily 1500.
>> 
> 
> True. And I have explained this in the I-D. But generally you would 
> have links in the network which have support 1500 byte or less 
> packets.

I'm not sure where is this generally true?  Which links generally
support 1500 or less MTU? IP over FiberChannel 65280, IP over SONET/SDH
65280, IP over FrameRelay 1600, IP over ATM PVC 9180.  All these are
larger than 1500, and in wide use.

> So sending packets on the .16 link >1500 bytes would result in 
> requiring fragmentation. So the recommendation for 1500 makes sense.

I am not very sure about that.  Backhauls have much larger MTUs than
access wireless links.

>> service flows for larger MTUs then the MTU should be 2048, the 
>> maximum allowed by the 802.16 MAC header".\
>> 
>> What do you think?
> 
> No... As I explained above, there are issues if you send packets > 
> 1500 bytes. Just because one link in the network is able to support 
> large packets is not enough. You have to consider the backhaul 
> capability as well.

Most backhauls support much more larger MTUs than 1500.  What is the
backhaul has MTUs smaller than 1600?

IPv6 is about the 1280 MTU, I think we agree we need to mention that.
You think it's not worth mentioning, because already known, but I think
it is worth mentioning 1280.

The IP fragmentation happens if packets are larger than smallest MTU on
one path.  Smallest MTU can't be smaller than 1280, because IPv6 doesn't
run over any link smaller than 1280.

But here we talk about the potential fragmentation between the IP stack
and its underlying link-layer, not about the IP path.  The link layer is
clearly capable and configurable to support larger MTUs than 1280 (up to
to 2048).

If we talk non-backhaul, but edge links, there indeed we can find links
with MTUs smaller than 1500, but they'll always be greater than 1280.
But then the only figure to mention is 1280 - and you seem to avoid that.

I do not see what's the detail motivation of the figure '1500'.  Why not
1501 for example.

What do others think?

Alex

---

From: "David Johnston" <[email-masked]>
Date: Mon, 18 Dec 2006 09:38:14 -0800

Alex,

" The 802.16 MAC 
header seems to allow for lengths up to 2^11 (len is encoded on 11 
bits).  So I think the IP stack could put packets as big as 2048 (2^11) 
on the 802.16 MAC, not necessarily 1500."

This doesn't apply at the MAC service interface. There is not
necessarily a 1:1 mapping between MSDUs and MPDUs. Fragmentation and
packing sit within the MAC.

The MTU of the 802.16 MAC CPS is infinite (just keep sending middle
fragments), and so in reality is implementation defined. The MAC service
MTU is either defined by the CS (The Ethernet specific part of the
packet CS does) or something higher up - in the case of the IP specific
part. The 16ng seems to be the right body to do it in the general case.
WiMax seems to be the body to define something they require for
certification.  

<caveat>
Keep in mind that the rules for 802 bridging demand that packets passing
between bridge ports with dissimilar MTUs, where the incoming packets is
larger that the outgoing bridge port can handle must be silently
discarded. So 802.16 might handle your packet, but the bridge might drop
it on the floor if it is larger than the attached Ethernet can handle.
Hence the general reluctance to go for larger MTUs than Ethernet bridges
will handle.
</caveat>

DJ

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: Saturday, December 16, 2006 9:09 AM
To: Basavaraj Patil
Cc: [email-masked]
Subject: Re: MTU recommendation? (was: [16NG] Re:
I-DACTION:draft-ietf-16ng-ipv6-over-ipv6cs-02.txt)

Basavaraj Patil wrote:
[...]

>    1661]) must be configured to have an MTU of at least 1280 octets;
it

What do you think?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 18 Dec 2006 18:54:28 +0100

Ok.  So what do you think that MTU figure should be?  We can't just say
'infinite'.

I mean the MTU the IP CS driver advertises, and the size of the memory
buffer the IP stack passes to it without being afraid the driver will
not accept it.

We know IPv6 is minimum 1280.  Raj says 1500 is better.

What do _you_ think?  Do you agree with 1500?  Why

I propose 2048 for the reasons cited.

Alex
PS: I agree this is not discussion of IP over Ethernet CS, but over IP
     CS, no Ethernet MAC header.

David Johnston wrote:
> Alex,
> 
> " The 802.16 MAC header seems to allow for lengths up to 2^11 (len is
> big as 2048 (2^11) on the 802.16 MAC, not necessarily 1500."
> 
> fragments), and so in reality is implementation defined. The MAC
> service MTU is either defined by the CS (The Ethernet specific part
> of the packet CS does) or something higher up - in the case of the IP
> specific part. The 16ng seems to be the right body to do it in the
> general case. WiMax seems to be the body to define something they
> require for certification.
> 
> <caveat> Keep in mind that the rules for 802 bridging demand that
> packets passing between bridge ports with dissimilar MTUs, where the
> incoming packets is larger that the outgoing bridge port can handle
> must be silently discarded. So 802.16 might handle your packet, but
> the bridge might drop it on the floor if it is larger than the
> attached Ethernet can handle. Hence the general reluctance to go for
> larger MTUs than Ethernet bridges will handle. </caveat>
> 
> DJ
> 
> 
> 
> -----Original Message----- From: Alexandru Petrescu
> [mailto:[email-masked]] Sent: Saturday, December 16,
> 2006 9:09 AM To: Basavaraj Patil Cc: [email-masked] Subject: Re: MTU
> recommendation? (was: [16NG] Re: 
>> Text added: The default MTU for IPv6 over 802.16 SHOULD be the same
>> as specified in RFC2460 which is 1500 octets.
> 
> means
> bits).  So I think the IP stack could put packets as big as 2048
> (2^11) on the 802.16 MAC, not necessarily 1500.
> 
> maximum allowed by the 802.16 MAC header".
> 
> What do you think?
> 
> Alex
> 
> 
> _______________________________________________ 16NG mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/16ng
> 
>

---

From: Jari Arkko <[email-masked]>
Date: Mon, 18 Dec 2006 20:28:52 +0200

David,
> on the 802.16 MAC, not necessarily 1500."
I believe that is what draft-ietf-16ng-ipv6-over-ipcs says.
However, this thread prompted me to re-read the
relevant sections, and I noticed that in the text
where you Basavaraj also explain the Wimax recommendation,
you say:

   The WiMAX forum [WMF] has specified the Max SDU size as 1522 octets.
   Hence the IPv6 path MTU can be 1500 octets.  However because of the
   overhead of the GRE tunnel used to transport IPv6 packets between the
   BS and AR and the 6 byte MAC header over the air interface, using a
   value of 1500 would result in fragmentation of packets.  It is
   recommended that the default MTU for IPv6 be set to 1400 octets for
   the MS in WiMAX networks.  Note that the 1522 octet specification is
   a WiMAX forum specification and not the size of the SDU that can be
   transmitted over 802.16, which is higher.

Its unclear how you know you are in a "Wimax Network". Particularly
from the point of view of a host attached to 802.16. Perhaps
you should indicate that the MTU is always included RAs when
< 2038.

--Jari

---

From: Fred Baker <[email-masked]>
Date: Mon, 18 Dec 2006 13:49:14 -0500

> I propose 2048 for the reasons cited.

There are a few boundaries that are useful, many that are kind of  
irrelevant.

You have in any packet a certain amount of overhead, which includes  
everything that isn't the direct payload. If I need to get a voice  
sample from here to there, for example, I have an RTP header, a UDP  
header, an IP header, and a link layer header and trailer. All of  
those are overhead from the perspective of the voice sample. The  
smaller the MTU that you choose, the larger this overhead is as a  
percentage of overall packet size and the more packets it presumably  
might take to get the same amount of data from here to there and  
therefore the more work  (interrupts, data copies, etc) that will  
happen in so doing. The larger the MTU you choose, the better those  
trade-offs move, and the greater the probability that the trailing  
CRC will not be adequate t detect transmission errors, and so  
robustness is reduced.

I would argue that picking a link layer MTU that is large enough to  
carry a 1500 byte IP4/IPv6 datagram has a lot to be said for it.  
Ethernet-attached systems like to send 1500 byte packets, and they  
should be allowed to. There is an argument along the same lines for  
9K byte IPv4/IPv6 datagrams, based on gigabit Ethernet packet sizes.  
I haven't looked at the CRC chosen for 802.16, so I don't know how  
that relates, but my gut tells me that the two CRCs are probably the  
same and probably have similar characteristics in the wild.

Speaking just for myself, while I'm not going to argue against an MTU  
between 1500 an 9200 bytes, I'm not sure I see the point. 802.16 is  
not going to be the only protocol used in the end-to-end sessions,  
any more than Ethernet is the only protocol, or PPP is, or 802.11, or  
Packet-on-Sonet. They will all be there at some point, end to end,  
and the path MTU will have to thread them all. So I would find myself  
picking between supporting a 1500 byte IP datagram and supporting a  
9200 byte IP datagram.

---

From: "David Johnston" <[email-masked]>
Date: Mon, 18 Dec 2006 13:14:46 -0800

I think there are two domains to the 802.16 MTU argument. 
	1) What must 802.16 support to handle the worst that is thrown
at it.
	2) What must an upper layer (say IP) expect to avoid trouble.

Case 1) Implementations of the MAC CPS (802.16 domain) should be able to
handle the largest thing that might be thrown at the MAC service. I.E.
4096 for most links, 16k for trunk links using jumbo packets. 4096 is
one power-of-2 greater than the power-of-2 size required to handle
Ethernet today (2048). Thus buying margin when the IETF and/or 802.1&3
change the rules. 802.3 is in the process of increasing their MTU to
accommodate their security subheaders in 802.1ae/af.

Case 2) In bridged scenarios, the MTU of the payload at the MAC service
should be set consistent with whatever Ethernet imposes, due to the
transitive nature of MTUs across 802 bridges. In IP-routed scenarios
draft-pagtzis-16ng-MTU-SDU-config-00.txt explains. 

DJ

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: Monday, December 18, 2006 9:54 AM
To: David Johnston
Cc: [email-masked]
Subject: Re: MTU recommendation? (was: [16NG] Re:

Alex