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

From: <[email-masked]>
Date: Tue, 17 Oct 2006 14:57:52 +0200

Hi Alex, 

[major-snip]

> >>> [snip]
> > [snip]
> >>> Actually this is how current cellular networks (3GPP and 3GPP2) 
> >>> work.
> >> You mean for 3GPP/3GPP2 IPv4?  I agree they so work for IPv4.  But
> >>  that is possible in IPv4 only because private non-routable 
> >> addresses exist in IPv4 - they don't exist in IPv6.  In one 
> >> particular IPv4 cellular network each mobile gets a 10.x.x.x/8 
> >> prefix.  But that is possible only because it's a 10 non-routable 
> >> address.
> >> 
> >> I don't think operators are inclined to build closed dedicated IPv6
> >>  systems where the mobiles are not reachable from the Internet.
> > 
> > The 3GPP/3GPP2 specifications say that you allocate a /64 per mobile
> >  in IPv6. The assumption is that the addresses would be of global 
> > scope.
> 
> Thanks, that is good to know, and confirms some of my 
> expectations.  Is 
> there any deployment of the 3GPP/3GPP2 specifications that say you
> allocate a /64 per mobile in IPv6, and the addresses are global scope?

You might want to check e.f. 3GPP TS23.030 sub-clause 9.2.1.1. Though
it doesn't state there that the prefix is /64. Anyway the prefix must be
unique
within its scope to each PDP context. On the other hand 29.061 state
that the
interface identifier is 64bits (generated by GGSN) etc.. At least our
(3GPP)
networks are configured in this way.

[major-snap]

> > Maybe I'm confused, but usually links have just one MTU. This is the
> >  case also for 2G/3G GPRS.
> 
> Yes, I agree in general we talk links have one MTU.
> 
> However, many cellular wireless links are asymmetric in nature, the
> download pipe is wider - because the typical use is to 
> download content
> (not to upload).  This can be seen easily with stacks that fragment
> outgoing packets because their next-hop routers tells them do so.

Haven't seen this happening in practise.. Dunno if the asymmetry e.g. in
GPRS ul/dl timeslots numbers should reflect in any way to MTU sizes.. I
doubt not.

> Finally, I agree with you that IP-friendly MAC-enabled IEEE 802 links
> are easier to specify and implement with symmetric MTU.
> 

Cheers,
	Jouni

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

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 17 Oct 2006 15:30:28 +0200

Jouni, thanks for the reply.

[email-masked] wrote:
>  it doesn't state there that the prefix is /64. Anyway the prefix
> must be unique within its scope to each PDP context. On the other
> hand 29.061 state that the interface identifier is 64bits (generated
> by GGSN) etc.. At least our (3GPP) networks are configured in this
> way.

How is this particular (3gpp) network configured?  Is it delivering one
prefix per mobile?  Is the mobile reachable from the IPv6 Internet?
Thanks!

>>  download pipe is wider - because the typical use is to download 
>> content (not to upload).  This can be seen easily with stacks that 
>> fragment outgoing packets because their next-hop routers tells them
>>  do so.
> 
> Haven't seen this happening in practise.. Dunno if the asymmetry e.g.
>  in GPRS ul/dl timeslots numbers should reflect in any way to MTU 
> sizes.. I doubt not.

Probably yes timeslot-MTU relationship, I have no practical way to check.

Alex

---

From: "Soininen Jonne (Nokia-NET/Espoo)" <[email-masked]>
Date: Tue, 17 Oct 2006 17:00:46 +0300

Alex,

> Probably yes timeslot-MTU relationship, I have no practical way to check.

There should be no relationship with the MTU to the timeslots. The timeslots
are a "lower-layer" issue. The convergence sub-layer should hide these
things from IP.

How did you find this issue? I would also be really interested in, which
network this occurred. Please, feel free to contact me also off-list if you
don't feel like sharing this info with everybody for whatever reason.

Cheers,

Jonne.

-- 
Jonne Soininen
Nokia

Tel: +358 40 527 46 34
E-mail: [email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 17 Oct 2006 16:29:26 +0200

Soininen Jonne (Nokia-NET/Espoo) wrote:
>>> Haven't seen this happening in practise.. Dunno if the asymmetry
>>> e.g. in GPRS ul/dl timeslots numbers should reflect in any way to
>>> MTU sizes.. I doubt not.
> There should be no relationship with the MTU to the timeslots. The
> timeslots are a "lower-layer" issue. The convergence sub-layer should
> hide these things from IP.
> 
> How did you find this issue? I would also be really interested in,
> which network this occurred. Please, feel free to contact me also
> off-list if you don't feel like sharing this info with everybody for
> whatever reason.

The timeslot potential reason of MTU asymmetry was suggested by Jouni.

How I found the MTU variance: have an IPv6 moving network behind an MR
connected to GPRS, and an IPv6 webserver on an LFN streaming MP3 towards
a client outside the UMTS network.  The MR sends IPv6-in-IPv6-in-IPv4 to
the UMTS network first-hop router.  MR's IPv4 stack receives
'packet-too-big' from the first-hop router, so it fragments the IPv4
sent packet, to a size smaller than the size of packets it receives.

In mobile WiMax or 802.16e - do we know whether the MS wireless link is
symmetric or asymmetric with respect to MTU?  Worth mentioning in the
draft?

Alex

---

From: "Soininen Jonne (Nokia-NET/Espoo)" <[email-masked]>
Date: Tue, 17 Oct 2006 17:58:37 +0300

Alex,

On 10/17/06 5:29 PM, "ext Alexandru Petrescu"
<[email-masked]> wrote:

[snip]
> The timeslot potential reason of MTU asymmetry was suggested by Jouni.

There is a remote possibility. However, this is not how GPRS was designed
and implemented in the implementations I know...

> sent packet, to a size smaller than the size of packets it receives.

Again, your packet-too-big seems to come _after_ the packet has traveled
over the GPRS network. Thus, the smaller MTU seems to be in the network
_behind_ the first-hop-router. I don't know if the packets travel a
different route to your client than coming down from the client.

If there would be a problem with the MTU of your GPRS link the packet would
not even travel to the first-hop-router (it would not fit the link MTU and
your MR would send a packet-too-big to your web server). You can check the
MTU of your GPRS interface on the MR.

Anyways, you case does not show there is an MTU-asymmetric link, but that
your packets are too big to a link in the network. It can easily happen as
you have multiple layers of tunneling.

> symmetric or asymmetric with respect to MTU?  Worth mentioning in the

It is symmetric. Anyways it does not matter. Every interface is set an MTU
(Maximum Transmission Unit) - to my understanding you don't set the
receiving side as the sending router/host is supposed to check that the
packet fits to the limits of the layer 2.

Thus, I don't think this has to be mentioned - it generally isn't.

Cheers,

Jonne.

-- 
Jonne Soininen
Nokia

Tel: +358 40 527 46 34

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 17 Oct 2006 17:27:15 +0200

> and implemented in the implementations I know...

Thanks, good to know.

> different route to your client than coming down from the client.

YEs, those paths are things one never knows.

> you have multiple layers of tunneling.

I'm not so sure about that.  Do you agree that usually the core network 
links have much larger MTU than edge wireless links?

> packet fits to the limits of the layer 2.

The MTU parameter set on a linux interface is often irrelevant when 
receiving a packet too big message.

> Thus, I don't think this has to be mentioned - it generally isn't.

Ok.

Alex