RE: 3gpp-analysis-04: use of NAT-PT in IPv6 UE -> IPv4 node

[Pekka Savola <pekkas@netcore.fi>]

On Tue, 22 Jul 2003, Soliman Hesham wrote:
>  > >  > Lots of things require state in the network, including 
>  > any kind of 
>  > >  > protocol translator.  Protocol translators mitigate the need 
>  > >  > for radio 
>  > >  > channels, 
>  > > 
>  > > => This is not related to radio channels, it's related
>  > > to the time and the resources consumed in the network.
>  > 
>  > This is very much related.  If you, using e.g. IPv6 proxies, 
>  > make it so
>  > that you basically never need IPv4, the time and resources 
>  > consumed for
>  > IPv4 in the network is much smaller.
> 
> => But what's the relevance of this to radio channels? 
> There is one physical network that supports an aggregate
> (X) amount of traffic, whether it's v4 or v6. 
> 
> My comment was related to the time it takes to setup the context 
> and the resources consumed in the SGSN and GGSN. 

The text in elmalki draft seems to suggest that there a UE with only v6 
PDP context requires one radio channel, while a UE with v4/v6 PDP contexts 
require two radio channels (regardless of the fact that the aggregate 
bandwidth usage is the same).

I don't know the radio technology well enough to to say whether this 
perception is true or not.

>  > my immediate
>  > reaction to that is that by reducing the amount of 
>  > concurrent state the
>  > problem could be handled.
>  > 
>  > This also helps to a lesser extent wrt. time consumed to 
>  > setup contexts
>  > (if there are free resources == few customers in the 
>  > network, you can set
>  > up contexts pre-emptively).
> 
> => I've lost you here, how do you make the decision
> that there are few customers in the network? How
> does the UE know that? 

I don't know what (if any) signalling there is between the UE and the
network where some hints about network utilization could be piggybacked.  
Probably a lot.

But even if there wasn't any, the first UE's could be programmed to open
both PDP contexts when they start, and possibly discard the other one if
it is not used in X minutes (or even keep it, no matter).
 
>  > If IMS requires translation, we may end up designing a 
>  > translation which
>  > suits IMS.  The previous sections don't indicate which 
>  > translation will be
>  > used for IMS, 
> 
> => What types of translation are there? We need IP
> address and port translation, hence NAPT-PT. 

No.

> The
> draft discusses how to install the translation
> state in the translator (i.e. installing it before 
> traffic goes through the translator). 

Yes, but for a very specific purpose only.

>    or that if IMS uses translation, the 
>  > translation would also
>  > be used in *any* other kind scenario.
> 
> => It doesn't, but how can you restrict
> that in an IETF spec? If a UE doesn't get an IPv4 context, 
> it will go through the translator.

Please, we're discussing the 3GPP solutions document.  We as the WG can do
it any way we see fit.  Hopefully the solutions are reasonable though.  
If operators or vendors want to do something else, that's their problem
and fine too.

We should not write the document based on what people think might happen,
but what we think *should* happen (but necessarily won't especially in all
cases).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings