#1220 closed request (fixed)

ietf network is really lossy in Sandringham.

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

Description

ietf-nat64 isn't great either, but it's a lot better.

I'm on the 5ghz network.

Change history (9)

comment:1 Changed 10 months ago by panda@…

Hi,

Thank you for reporting.
Could you tell me the BSSID you associated with, and your MAC address if possible to investigate the problem in detail?

Thank you.
-- Hirochika Asai

comment:2 in reply to:  2 ; Changed 10 months ago by mellon@…

On Mar 20, 2018, at 4:11 PM, IETF Tickets/NOC <tickets@meeting.ietf.org> wrote:
> Could you tell me the BSSID you associated with, and your MAC address if
> possible to investigate the problem in detail?

BSSID=70:70:8b:09:0c:64
MAC=78:4f:43:56:67:0e

I had switched away, and have now switched back, but the BSSID may or may not be the same.   I'm seeing fairly bad behavior (bufferbloat-ish):

cavall% ping toccata.fugue.com
PING toccata.fugue.com (139.162.145.38): 56 data bytes
64 bytes from 139.162.145.38: icmp_seq=0 ttl=52 time=286.433 ms
Request timeout for icmp_seq 1
64 bytes from 139.162.145.38: icmp_seq=1 ttl=52 time=1293.885 ms
64 bytes from 139.162.145.38: icmp_seq=2 ttl=52 time=1067.084 ms
64 bytes from 139.162.145.38: icmp_seq=3 ttl=52 time=843.348 ms
64 bytes from 139.162.145.38: icmp_seq=4 ttl=52 time=25.080 ms
64 bytes from 139.162.145.38: icmp_seq=5 ttl=52 time=28.085 ms
64 bytes from 139.162.145.38: icmp_seq=6 ttl=52 time=23.939 ms
64 bytes from 139.162.145.38: icmp_seq=7 ttl=52 time=683.978 ms
64 bytes from 139.162.145.38: icmp_seq=8 ttl=52 time=1131.666 ms
64 bytes from 139.162.145.38: icmp_seq=9 ttl=52 time=897.033 ms
64 bytes from 139.162.145.38: icmp_seq=10 ttl=52 time=618.279 ms
Request timeout for icmp_seq 12
64 bytes from 139.162.145.38: icmp_seq=12 ttl=52 time=1160.301 ms
64 bytes from 139.162.145.38: icmp_seq=13 ttl=52 time=1076.535 ms
64 bytes from 139.162.145.38: icmp_seq=14 ttl=52 time=100.269 ms
64 bytes from 139.162.145.38: icmp_seq=15 ttl=52 time=47.395 ms
64 bytes from 139.162.145.38: icmp_seq=16 ttl=52 time=25.901 ms
64 bytes from 139.162.145.38: icmp_seq=17 ttl=52 time=1465.954 ms
64 bytes from 139.162.145.38: icmp_seq=18 ttl=52 time=1238.859 ms
64 bytes from 139.162.145.38: icmp_seq=19 ttl=52 time=1009.590 ms
64 bytes from 139.162.145.38: icmp_seq=20 ttl=52 time=150.945 ms
64 bytes from 139.162.145.38: icmp_seq=21 ttl=52 time=868.972 ms
64 bytes from 139.162.145.38: icmp_seq=22 ttl=52 time=1317.242 ms
64 bytes from 139.162.145.38: icmp_seq=23 ttl=52 time=1234.365 ms
64 bytes from 139.162.145.38: icmp_seq=24 ttl=52 time=232.498 ms
64 bytes from 139.162.145.38: icmp_seq=25 ttl=52 time=25.153 ms
64 bytes from 139.162.145.38: icmp_seq=26 ttl=52 time=27.786 ms
64 bytes from 139.162.145.38: icmp_seq=27 ttl=52 time=38.715 ms
64 bytes from 139.162.145.38: icmp_seq=28 ttl=52 time=48.619 ms
64 bytes from 139.162.145.38: icmp_seq=29 ttl=52 time=851.935 ms
64 bytes from 139.162.145.38: icmp_seq=30 ttl=52 time=960.011 ms
64 bytes from 139.162.145.38: icmp_seq=31 ttl=52 time=1180.258 ms
64 bytes from 139.162.145.38: icmp_seq=32 ttl=52 time=949.997 ms
Request timeout for icmp_seq 34
Request timeout for icmp_seq 35
Request timeout for icmp_seq 36
64 bytes from 139.162.145.38: icmp_seq=35 ttl=52 time=2798.006 ms
64 bytes from 139.162.145.38: icmp_seq=36 ttl=52 time=1797.795 ms
64 bytes from 139.162.145.38: icmp_seq=37 ttl=52 time=795.443 ms
64 bytes from 139.162.145.38: icmp_seq=38 ttl=52 time=517.517 ms
64 bytes from 139.162.145.38: icmp_seq=39 ttl=52 time=767.851 ms
64 bytes from 139.162.145.38: icmp_seq=41 ttl=52 time=882.189 ms
64 bytes from 139.162.145.38: icmp_seq=42 ttl=52 time=322.325 ms
64 bytes from 139.162.145.38: icmp_seq=43 ttl=52 time=967.449 ms
64 bytes from 139.162.145.38: icmp_seq=44 ttl=52 time=921.399 ms
Request timeout for icmp_seq 46
64 bytes from 139.162.145.38: icmp_seq=47 ttl=52 time=154.758 ms
Request timeout for icmp_seq 48
64 bytes from 139.162.145.38: icmp_seq=48 ttl=52 time=1073.884 ms
64 bytes from 139.162.145.38: icmp_seq=49 ttl=52 time=833.271 ms
64 bytes from 139.162.145.38: icmp_seq=50 ttl=52 time=1374.309 ms
64 bytes from 139.162.145.38: icmp_seq=51 ttl=52 time=1141.865 ms
64 bytes from 139.162.145.38: icmp_seq=52 ttl=52 time=289.766 ms
64 bytes from 139.162.145.38: icmp_seq=53 ttl=52 time=126.955 ms
64 bytes from 139.162.145.38: icmp_seq=54 ttl=52 time=26.512 ms
64 bytes from 139.162.145.38: icmp_seq=55 ttl=52 time=30.666 ms
64 bytes from 139.162.145.38: icmp_seq=56 ttl=52 time=24.056 ms
64 bytes from 139.162.145.38: icmp_seq=57 ttl=52 time=25.201 ms
64 bytes from 139.162.145.38: icmp_seq=58 ttl=52 time=1487.136 ms
64 bytes from 139.162.145.38: icmp_seq=59 ttl=52 time=1050.626 ms
64 bytes from 139.162.145.38: icmp_seq=60 ttl=52 time=599.596 ms
64 bytes from 139.162.145.38: icmp_seq=61 ttl=52 time=821.046 ms
^C
--- toccata.fugue.com ping statistics ---
64 packets transmitted, 56 packets received, 12.5% packet loss
round-trip min/avg/max/stddev = 23.939/709.638/2798.006/572.230 ms

comment:3 Changed 10 months ago by panda@…

Resolution: fixed
Status: newclosed

Hi,

Thank you for your detailed information.

You were on a different AP with low signal bad SNR according to our log. I'll continue to investigate and adjust the radio of APs, but I think you get better connectivity by switching AP to different one.

I'll close this ticket, but feel free to reopen this ticket if you experience any bad quality.

Thank you for reporting, again.
Hirochika Asai

comment:4 in reply to:  4 ; Changed 10 months ago by mellon@…

Resolution: fixed
Status: closedreopened
On Mar 20, 2018, at 4:36 PM, IETF Tickets/NOC <tickets@meeting.ietf.org> wrote:
> I'll close this ticket, but feel free to reopen this ticket if you
> experience any bad quality.

I'm now on NAT64 and still seeing bufferbloat-like behavior.   I'm not seeing dropped packets anymore, but performance is still very bad.

BSSID = 70:70:8b:08:fe:2x

comment:5 in reply to:  5 ; Changed 10 months ago by mellon@…

On Mar 20, 2018, at 4:44 PM, IETF Tickets/NOC <tickets@meeting.ietf.org> wrote:
> BSSID = 70:70:8b:08:fe:2x

2c, not 2x

comment:6 Changed 10 months ago by panda@…

Thank you for reporting the issue again.

We have investigated this issue and found two possible causes:

  1. Channels of several APs of ours conflict with hotel's ones.
  2. Some APs are overloaded by heavy hitters.

We have rearranged the channels and are working with the hotel IT to solve them.

Thank you.
Hirochika Asai

comment:7 in reply to:  7 ; Changed 10 months ago by mellon@…

Thank you!  I'm not there anymore but will check it out next time!

On Mar 20, 2018 18:28, "IETF Tickets/NOC" <tickets@meeting.ietf.org> wrote:

> #1220: ietf network is really lossy in Sandringham.
> ---------------------------+-----------------------------------
>       Reporter:  mellon@…  |                Owner:  < default >
>           Type:  request   |               Status:  reopened
>       Priority:  tbd       |            Milestone:  ietf-101
>      Component:  incoming  |           Resolution:
>       Keywords:            |  My Current Location:
> My MAC  Address:           |                My OS:
> ---------------------------+-----------------------------------
>
> Comment (by panda@…):
>
>  Thank you for reporting the issue again.
>
>  We have investigated this issue and found two possible causes:
>  1. Channels of several APs of ours conflict with hotel's ones.
>  2. Some APs are overloaded by heavy hitters.
>
>  We have rearranged the channels and are working with the hotel IT to solve
>  them.
>
>  Thank you.
>  Hirochika Asai
>
> --
> Ticket URL: <https://tickets.meeting.ietf.org/ticket/1220#comment:6>
> IETF Tickets/NOC <https://tickets.meeting.ietf.org>
> IETF Meeting Tickets - NOC pages
>

comment:8 Changed 10 months ago by odonoghue@…

Component: incomingwireless
Owner: changed from < default > to panda@…
Status: reopenedassigned

comment:9 Changed 10 months ago by jim@…

Resolution: fixed
Status: assignedclosed

With Asai-san's reconfiguration complete, we're considering this closed. If you find further issues, please open a new ticket. Thanks for reporting the issue!

-Jim

Note: See TracTickets for help on using tickets.