Opened 3 years ago

Closed 3 years ago

Last modified 5 weeks ago

#884 closed defect (fixed)

Slow tcp activity on ietf-nat64

Reported by: mellon@… Owned by: panda@…
Priority: tbd Milestone: ietf-091
Component: nat64 Keywords:
Cc: My Current Location:
My MAC Address: My OS:

Description

Google maps was tiling _really_ slowly for some reason.   I assume that it's v6-capable, so I don't know why this would be the case.   This is happening on Chrome on OSX Mavericks (10.9, I think).   It's faster on ietf-a, although still felt a bit sluggish.

Change history (16)

comment:1 Changed 3 years ago by llynch@…

Component: incomingnat64
Owner: changed from llynch@… to nkukich@…
Status: newassigned
Type: requestdefect

This one is for the nat64 folk

comment:2 Changed 3 years ago by mellon@…

BTW, I forgot to mention: this is in Coral IV.   Also, it's not happening at the moment.

comment:3 Changed 3 years ago by jim@…

Owner: changed from nkukich@… to chelliot@…

comment:4 in reply to:  2 Changed 3 years ago by chelliot@…

Replying to mellon@…:

BTW, I forgot to mention: this is in Coral IV.   Also, it's not happening at the moment.

Ted,

I'm sorry we didn't respond sooner. I'm checking into this and either Asai-san or I will get back to you soon.

It does work for me, if slow.

By the way, we've asked for a redundant A10 box and/or a newer (and hopefully faster) box.

Chris.

comment:5 Changed 3 years ago by panda@…

Hi Ted,

I'm sorry for our late response.

I have checked the CPU utilization history on the NAT64 box but cannot find any excessive load in these 72 hours. I tried to reproduce this issue by traveling around the world and cities on the google maps for a couple of minutes with Google Chrome and OS X Yosemite (10.10), but it worked fine and the utilization of each CPU didn’t exceed 5%.

It might be an issue of WiFi?. To isolate the problem, could you please provide your WiFi? association information (e.g., BSSID, channel and RSSI) when this problem occurs again? Note that ietf-nat64 provides its service on 2.4GHz as well as 5GHz while ietf-a does only on 5GHz.

The WiFi? information is obtained by one of the following ways:
1) GUI: Clock the WiFi? icon on your menu bar while pressing the “option” key
or
2) CLI: /System/Library/PrivateFrameworks?/Apple80211.framework/Versions/Current/Resources/airport -I

Hirochika Asai

comment:6 in reply to:  2 Changed 3 years ago by chelliot@…

Replying to mellon@…:

BTW, I forgot to mention: this is in Coral IV.   Also, it's not happening at the moment.

Ted,

I'm sorry we didn't respond sooner. I'm checking into this and either Asai-san or I will get back to you soon.

It does work for me, if slow.

By the way, we've asked for a redundant A10 box and/or a newer (and hopefully faster) box.

Chris.

comment:7 in reply to:  description Changed 3 years ago by chelliot@…

Replying to mellon@…:

Google maps was tiling _really_ slowly for some reason.   I assume that it's v6-capable, so I don't know why this would be the case.   This is happening on Chrome on OSX Mavericks (10.9, I think).   It's faster on ietf-a, although still felt a bit sluggish.

Ted,

I think the issue is the 2.4Ghz spectrum and radio conifig here. Please verify if you see this performance issue when you are on a 2.4Ghz radio and not when you're on 5Ghz.

We have challenges with 2.4Ghz here for two reasons--both the contention from other uses of 2.4, including APs other than ours, as well as the changes we've made to allow those with Intel Centrino cards to use our network. So I highly recommend using 5Ghz, obviously.

I'm writing a proposal that, for Dallas, we revamp our SSID plan entirely. As part of this, I'm proposing that we both encrypt nat64 and put it on 5Ghz only. Thoughts?

Chris.

comment:8 Changed 3 years ago by jim@…

Ted,

I'm guessing that you're quite busy, but we'd love your input on the NAT64 stuff. Chris and Asai-san had some questions for you up-ticket. If you're no longer interested in pursuing this, please let us know and we'll close out the ticket, but we'd much rather get your input on the future of NAT64.

  • Jim

comment:9 Changed 3 years ago by mellon@…

On Nov 13, 2014, at 8:05 AM, IETF Meeting/NOC <tickets@meeting.ietf.org> wrote:
>     I'm guessing that you're quite busy, but we'd love your input on the
> NAT64 stuff. Chris and Asai-san had some questions for you up-ticket. If
> you're no longer interested in pursuing this, please let us know and we'll
> close out the ticket, but we'd much rather get your input on the future of
> NAT64.

Thanks.   The behavior does appear to be happening right now in Hibiscus.   Google maps is loading very slowly.   Could it be port starvation?

comment:10 Changed 3 years ago by mellon@…

On Nov 12, 2014, at 1:13 PM, IETF Meeting/NOC <tickets@meeting.ietf.org> wrote:
> We have challenges with 2.4Ghz here for two reasons--both the contention
> from other uses of 2.4, including APs other than ours, as well as the
> changes we've made to allow those with Intel Centrino cards to use our
> network. So I highly recommend using 5Ghz, obviously.

I am not able to connect to the 2.4-only network, so I can't tell if the problem is related to that.

> I'm writing a proposal that, for Dallas, we revamp our SSID plan entirely.
> As part of this, I'm proposing that we both encrypt nat64 and put it on
> 5Ghz only. Thoughts?

I think that's fine.   Not many devices are incapable of 5GHz at this point, and they are all old devices that are least likely to work well on nat64 anyway, so I don't see a downside to it.   I'd love it if it were encrypted; it might slightly reduce use, but OTOH it might prod more people to use the 802.1x infrastructure, so I think it's kind of a wash.

comment:11 in reply to:  9 Changed 3 years ago by panda@…

Replying to mellon@…:

Thanks.   The behavior does appear to be happening right now in Hibiscus.   Google maps is loading very slowly.   Could it be port starvation?

Ted,

Thank you for the further information.

Google maps is IPv6-capable as long as you access to www.google.com etc. In this case, NAT64 (i.e., AAAA recored is resolved as an address of 64:ff9b::/96) is not used, and consequently, it could not be port starvation for Google maps.

I've checked that www.google.com, www.google.fr, and ww.google.co.jp have non-translated AAAA records but not checked for other google domains. I guess other google domains also have non-translated AAAA records, but I'm not sure. Please report if one you're using doesn't.

Hirochika Asai

Last edited 3 years ago by panda@… (previous) (diff)

comment:12 Changed 3 years ago by chelliot@…

Ted,

The ietf-nat64 SSID exists on both radios on our APs--and one works at
2.4Ghz and the other at 5Ghz. Your laptop chooses what looks like the best
connection, and it doesn't always choose wisely. We try to help that by
providing networks such as the ietf-a SSID that only exists on the 5Ghz
radio. I think you have a MacBook--if so, you can click on the wifi icon on
the top menu bar while holding down the option button and you'll see much
more information on your current connection.

In any case, making ietf-nat64 5Ghz-only in Dallas sounds like a plan.

Please come to the NOC if you'd like to discuss the performance of nat64
more. I'll be closing this ticket.

Thanks!
Chris.

On Thu, Nov 13, 2014 at 9:47 AM, Ted Lemon <mellon@fugue.com> wrote:

> On Nov 12, 2014, at 1:13 PM, IETF Meeting/NOC <tickets@meeting.ietf.org>
> wrote:
> > We have challenges with 2.4Ghz here for two reasons--both the contention
> > from other uses of 2.4, including APs other than ours, as well as the
> > changes we've made to allow those with Intel Centrino cards to use our
> > network. So I highly recommend using 5Ghz, obviously.
>
> I am not able to connect to the 2.4-only network, so I can't tell if the
> problem is related to that.
>
> > I'm writing a proposal that, for Dallas, we revamp our SSID plan
> entirely.
> > As part of this, I'm proposing that we both encrypt nat64 and put it on
> > 5Ghz only. Thoughts?
>
> I think that's fine.   Not many devices are incapable of 5GHz at this
> point, and they are all old devices that are least likely to work well on
> nat64 anyway, so I don't see a downside to it.   I'd love it if it were
> encrypted; it might slightly reduce use, but OTOH it might prod more people
> to use the 802.1x infrastructure, so I think it's kind of a wash.
>
>


-- 
Chris Elliott
chelliot@pobox.com

comment:13 Changed 3 years ago by mellon@…

On Nov 13, 2014, at 4:03 PM, Chris Elliott <chelliot@pobox.com> wrote:
> In any case, making ietf-nat64 5Ghz-only in Dallas sounds like a plan.

Okay, sounds good.   Yes, close the ticket.   Thanks for that pointer to option-click on the wifi icon—that's very useful!


comment:14 Changed 3 years ago by panda@…

Owner: changed from chelliot@… to panda@…
Status: assignedaccepted

comment:15 Changed 3 years ago by jim@…

Resolution: fixed
Status: acceptedclosed

Closing the ticket as requested.

  • Jim

comment:16 Changed 5 weeks ago by Rick Alfvin

Milestone: ietf-91ietf-091

Milestone renamed

Note: See TracTickets for help on using tickets.