Subject: [Int-area] Review of draft-fleischhauer-ipv4-addr-saving-01

From: Tina TSOU <[email-masked]>
Date: Tue, 22 Nov 2011 00:39:18 +0000

Hi,
I volunteered to review draft-fleischhauer-ipv4-addr-saving-01 in Taipei meeting.

This is definitely a great idea but what happens in the following scenario:
When a user wants to connect to a site, say google.com , by default DNS resolver will give a AAAA record( IPv6 address for Google). What if the site user requests to, is not v6 capable,  we waste time first trying to resolve the DNS over v6 and then initiate a IPCP configure request to obtain IPv4 address + DNS resolver address etc etc.

Doesn't this affect the performance? Moreover as v6 connectivity is still in its nascent stage, there are more chances of broken or mis configured links over v6. In that case, frequently the user would be switched to IPv4, get configurations, release IPv4 address parameters etc etc.

I know we tried to put v6 on the higher premise though...

Thanks,
Tina

---

From: <[email-masked]>
Date: Tue, 22 Nov 2011 16:22:12 +0100

Dear Tina,

thank you very much for your comments.
Please find my answer below.

Best

KARSTEN

> -----Ursprüngliche Nachricht-----
> Von: [email-masked]
> [mailto:[email-masked]] Im Auftrag von Tina TSOU
> Gesendet: Dienstag, 22. November 2011 01:39
> An: [email-masked]
> Betreff: [Int-area] Review of draft-fleischhauer-ipv4-addr-saving-01
>
> Hi,
> I volunteered to review
> draft-fleischhauer-ipv4-addr-saving-01 in Taipei meeting.
>
> When a user wants to connect to a site, say google.com , by
> default DNS resolver will give a AAAA record( IPv6 address
> for Google). What if the site user requests to, is not v6
> capable,  we waste time first trying to resolve the DNS over
> v6 and then initiate a IPCP configure request to obtain IPv4
> address + DNS resolver address etc etc.

Yes this can occur, but just for the first IPv4 packet.
In comparision to a scenario where we would use 2 different PPP
single stack sessions (one session for IPv4 the other for IPv6),
we do not need to set up the whole PPP session with LCP, Authentication and NCP.
We need only establish IPCP as NCP.

Today we have the need for set up the whole PPP session when IPv4 connectivity is
requested already in a IPv4-only deployment.
Here no significant problem reports are known.
The application can wait and/or the HG has buffer capabilities which
ensure the forwarding of the packetz as soon as IPv4 connectivity is established.
So we would not expect major problems.
>
> Doesn't this affect the performance? Moreover as v6
> connectivity is still in its nascent stage, there are more
> chances of broken or mis configured links over v6. In that
> case, frequently the user would be switched to IPv4, get
> configurations, release IPv4 address parameters etc etc.
I can here just speak for DT.
We are implementing Dual-Stack.
That means also that we will offer
for IPv4 and IPv6 the same quality level.
When outside of our network IPv6 conectivity is broken,
content provider should ensure that their DNS and network etc. is well configured.
But this is also needed for IPv4 UDP/TCP port sharing scenarios.
Nevertheless once the user has a IPv4 address he can use this as long as needed.
So no quality of experience degradation is expected.

---

From: Tina TSOU <[email-masked]>
Date: Tue, 22 Nov 2011 22:31:06 +0000

Dear Karsten,
Please see comments inline.

Thanks,
Tina

From: <[email-masked]<mailto:[email-masked]>>
Date: November 22, 2011 7:22:12 AM PST
To: <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>
Subject: AW: Review of draft-fleischhauer-ipv4-addr-saving-01
Dear Tina,

Best

KARSTEN

-----Ursprüngliche Nachricht-----
Von: [email-masked]<mailto:[email-masked]>
[mailto:[email-masked]] Im Auftrag von Tina TSOU
Gesendet: Dienstag, 22. November 2011 01:39
An: [email-masked]<mailto:[email-masked]>
Betreff: [Int-area] Review of draft-fleischhauer-ipv4-addr-saving-01

Hi,
I volunteered to review

This is definitely a great idea but what happens in the
following scenario:
When a user wants to connect to a site, say google.com<http://google.com> , by
default DNS resolver will give a AAAA record( IPv6 address
for Google). What if the site user requests to, is not v6
capable,  we waste time first trying to resolve the DNS over
v6 and then initiate a IPCP configure request to obtain IPv4
address + DNS resolver address etc etc.

>>Agreed, for a single application, only for the first IPv4 packet. But in a worst case scenario, the user can open 10 applications and for each first ipv6 connectivity will be the default.
Also say the user has switched to IPv4, and according to the timer, ended the IPCP session, released the v4 addr and other parameters. Now again when it opens an application, it may be possible that the next site also faces the same problem of not connecting over v6 and the whole process of IPCP will be repeated. So as I had mentioned that outside a Telco's n/w where it cannot guarantee v6 connectivity, the probability of broken links over v6 is higher in the upcoming years. So  some users can have degraded performance. This is does not ensure production quality service, its more on terms of best effort service.

Thanks,
Tina

---

From: <[email-masked]>
Date: Mon, 28 Nov 2011 10:14:25 +0100

Dear Tina,

see below.

Best

KARSTEN
> Von: Tina TSOU [mailto:[email-masked]]
> Gesendet: Dienstag, 22. November 2011 23:31
> An: Fleischhauer, Karsten
> Cc: [email-masked]
> Betreff: RE: AW: Review of draft-fleischhauer-ipv4-addr-saving-01
>
> Dear Karsten,
>>From: <[email-masked]>
>>To: <[email-masked]>, <[email-masked]>
>>>When a user wants to connect to a site, say
>>>google.com <http://google.com>  , by
>Agreed, for a single application, only for the first
>IPv4 packet. But in a worst case scenario, the user can open
>10 applications and for each first ipv6 connectivity will be
>the default.
>Also say the user has switched to IPv4, and according
>to the timer, ended the IPCP session, released the v4 addr
>and other parameters. Now again when it opens an application,
>it may be possible that the next site also faces the same
>problem of not connecting over v6 and the whole process of
>IPCP will be repeated.

The value of the "IPv4 traffic idle timer" should be similar to
a NAT binding timer in a NAT device.
Because we are not intending to be application aware
(as it is in a NAT) we would use the biggest common value, for instance 10 or 20 minutes.
That is also needed to avoid problems with applicatione whiche require some kind
of regular registrations/keep-alives.
So in general ths first IPv4 application will have a small delay.
In any case the value of the "IPv4 traffic idle timer" should be configurable.

>So as I had mentioned that outside a
>Telco's n/w where it cannot guarantee v6 connectivity, the
>probability of broken links over v6 is higher in the upcoming
>years. So  some users can have degraded performance. This is
>does not ensure production quality service, its more on terms
>of best effort service.

This is IMHO a general problem and will influence each IPv6
migration solution. E.g. also an application behind a DS-lite
implementation would first try IPv6 and thereafter IPv4.
I see here not a direct relation to our draft.
Maybe the delay issue can be solved with the HE implementation.
But also HE could cause problems...

>connectivity is still in its nascent stage,
>there are more chances of broken or mis configured links over
>Iv6. In that case, frequently the user would be switched to IPv4,
>get configurations, release IPv4 address parameters etc etc.
>
As already mentioned above we will have a configurable
"IPv4 traffic idle timer" on the PPP client/HG.
On the end we have to find here a compromise
between address saving/efficiency, load on the systems as well a custumer experience.
Our experience for pure Dual-Stack implementations shows also here
challenges regarding memory consumption, performance etc.
Maybe the reduction of a part of Dual-Stack sessions to single-stack sessions
could provide here a load reduction.