Re: Issue with Geolocation in Lasvegas

[Christopher Hawker]

As Peter and I have mentioned, you'll need to register a geofeed with
Google. An example can be downloaded from
https://isp.google.com/static/downloads/example-geo-feed.csv and registered
in the ISP Portal.

Having said that, it may be worthwhile checking-in with your internal IP
Network Operations team (if you don't have access to manage this). Being
Qualcomm, I'd imagine relationships with Google would already exist.

Regards,
Christopher H.

On Thu, 4 Jan 2024 at 18:28, Raja Sekhar Gullapalli 
wrote:

> Hi Christopher,
>
>
>
> It is used only in continental US & we also reported this issue to at
> n...@google.com.
>
>
>
> Any further info to be provided to resolve this issue.
>
>
>
> Regards,
>
> Raja
>
>
>
>
>
> *From:* Christopher Hawker 
> *Sent:* Thursday, January 4, 2024 12:54 PM
> *To:* Raja Sekhar Gullapalli 
> *Cc:* nanog@nanog.org
> *Subject:* Re: Issue with Geolocation in Lasvegas
>
>
>
> *WARNING:* This email originated from outside of Qualcomm. Please be wary
> of any links or attachments, and do not enable macros.
>
> Looks like (according to RDNS) it's a "global NAT" address. Is it only
> being used in the continental US, or other countries?
>
>
>
> If the former, check that geofeeds are correctly configured and registered
> with Google in their ISP Portal.
>
>
>
> If the latter, you're going to encounter issues.
>
>
>
> Regards,
>
> Christopher H.
>
>
>
> On Thu, 4 Jan 2024 at 18:14, Raja Sekhar Gullapalli via NANOG <
> nanog@nanog.org> wrote:
>
>
>
> Team,
>
>
>
> We are having issues in our lasvegas office & it shows geolocation in all
> browsers as Israel instead of US region when we access news.google.com in
> our PC.
>
>
>
> Our public ip is 129.46.96.20.
>
>
>
> Can you help to whom we can contact to resolve the issue.
>
>
>
>
>
> Regards,
>
> Raja
>
>
>
>
>
>

RE: Issue with Geolocation in Lasvegas

[Raja Sekhar Gullapalli via NANOG]

Hi Christopher,

It is used only in continental US & we also reported this issue to at 
n...@google.com.

Any further info to be provided to resolve this issue.

Regards,
Raja


From: Christopher Hawker 
Sent: Thursday, January 4, 2024 12:54 PM
To: Raja Sekhar Gullapalli 
Cc: nanog@nanog.org
Subject: Re: Issue with Geolocation in Lasvegas


WARNING: This email originated from outside of Qualcomm. Please be wary of any 
links or attachments, and do not enable macros.
Looks like (according to RDNS) it's a "global NAT" address. Is it only being 
used in the continental US, or other countries?

If the former, check that geofeeds are correctly configured and registered with 
Google in their ISP Portal.

If the latter, you're going to encounter issues.

Regards,
Christopher H.

On Thu, 4 Jan 2024 at 18:14, Raja Sekhar Gullapalli via NANOG 
mailto:nanog@nanog.org>> wrote:

Team,

We are having issues in our lasvegas office & it shows geolocation in all 
browsers as Israel instead of US region when we access 
news.google.com in our PC.

Our public ip is 129.46.96.20.

Can you help to whom we can contact to resolve the issue.


Regards,
Raja

Re: Issue with Geolocation in Lasvegas

[Peter Potvin via NANOG]

For Google-related sites specifically and if you haven't already, it's
worth publishing an RFC8805-compliant geofeed and submitting it to them via
their ISP portal at https://isp.google.com/ if you have an account with the
announcing ASN affiliated to it. This is assuming that the IP you specified
is linked to an organization and network you're affiliated with, which
based on your email's domain and the announcing ASN is most likely the case.

For other sites and geolocation databases, it's worth submitting the same
geofeed to each DB/provider individually via email or by following the
information on https://geolocatemuch.com/ to enable other DBs/providers to
automatically discover and update their databases.

Regards,
Peter Potvin


On Thu, Jan 4, 2024 at 2:17 AM Raja Sekhar Gullapalli via NANOG <
nanog@nanog.org> wrote:

>
>
> Team,
>
>
>
> We are having issues in our lasvegas office & it shows geolocation in all
> browsers as Israel instead of US region when we access news.google.com in
> our PC.
>
>
>
> Our public ip is 129.46.96.20.
>
>
>
> Can you help to whom we can contact to resolve the issue.
>
>
>
>
>
> Regards,
>
> Raja
>
>
>
>
>

Re: Issue with Geolocation in Lasvegas

[Christopher Hawker]

Looks like (according to RDNS) it's a "global NAT" address. Is it only
being used in the continental US, or other countries?

If the former, check that geofeeds are correctly configured and registered
with Google in their ISP Portal.

If the latter, you're going to encounter issues.

Regards,
Christopher H.

On Thu, 4 Jan 2024 at 18:14, Raja Sekhar Gullapalli via NANOG <
nanog@nanog.org> wrote:

>
>
> Team,
>
>
>
> We are having issues in our lasvegas office & it shows geolocation in all
> browsers as Israel instead of US region when we access news.google.com in
> our PC.
>
>
>
> Our public ip is 129.46.96.20.
>
>
>
> Can you help to whom we can contact to resolve the issue.
>
>
>
>
>
> Regards,
>
> Raja
>
>
>
>
>

Issue with Geolocation in Lasvegas

[Raja Sekhar Gullapalli via NANOG]

Team,

We are having issues in our lasvegas office & it shows geolocation in all 
browsers as Israel instead of US region when we access news.google.com in our 
PC.

Our public ip is 129.46.96.20.

Can you help to whom we can contact to resolve the issue.


Regards,
Raja

RPKI's 2023 Year in Review - growth, governments, and innovation

[Job Snijders via NANOG]

Dear all,

Happy new year everyone! Having just closed chapter 2023 - let's look
back at the previous year.

In this memo I'll share some RPKI statistics, summarize highlights from
the IETF Standards Development process, and reflect on emerging trends.


Year to Year Growth of the distributed RPKI database
===

A straight-forward method to compare to last year is to look at the
RPKI's absolute numbers.

The below table was constructed by comparing two December 31st
RPKIviews.org snapshots [1] of validated RPKI caches, primed with the
ARIN, AFRINIC, APNIC, LACNIC, and RIPE NCC Trust Anchors.

   2022-12-31  2023-12-31
Total cache size (KiB): 1,240,572   1,546,728 (+25%)
Total number of files (objects):  242,969 309,802 (+27%)
Publication servers (FQDNs):   52  63 (+21%)
Certification authorities: 34,901  40,511 (+16%)
Route origin authorizations:  138,323 188,345 (+36%)
Unique VRPs:  390,752 497,341 (+27%)
IPv4 addresses covered: 1,354,270,410   2,502,293,068 (+85%)
IPv6 addresses covered: 9,447 * 10^30  17,263 * 10^30 (+83%)
Unique origin ASNs in ROAs:34,455  40,656 (+18%)

The number of IP addresses covered by ROAs almost doubled compared to
last year. More than half the ASes in the global Internet routing system
are listed as Origin AS in at least one ROA. EOY'23 more unique IPv6
prefix-origin pairs in the DFZ are covered by ROAs than not, with IPv4
likely to follow crossing this threshold in Q1 2024.

Kentik [2] estimates that more than half of IP traffic is destined
towards ROA covered destinations. APNIC Labs [3] estimates the global
"I-Rov Filtering Rate" to be at 22.69% now. These numbers mean it will
be worth your while to create and use ROAs for BGP Origin Validation.

In short: it's all up and to the right. :-)


Increased Government Interest in Internet Routing Security
===

Following the FCC's launch of an inquiry into Internet Routing
Vulnerabilities in 2022, in 2023 the agency followed up with a BGP
Security Workshop hosted by the Public Safety and Homeland Security
Bureau [4], the industry seemed well represented with key players
participating.

While the USG is still sizing up the industry's posture and
contemplating whether regulation is warranted, in the Netherlands the
government itself aspires to lead by example: in 2023 the Dutch
government committed to use RPKI by the end of 2024 on all new and
existing IT systems it operates [5]. Note that this ambition includes
both signing ROAs and validating BGP messages! I hope they succeed.

Will more governments follow the Dutch lead in 2024?


The Rise Of Initiatives Re-evaluating The RPKI Trust Model
===

As the industry saw unprecedented turmoil in the realm of governance of
Regional Internet Registries in 2023, two interesting initiatives arose,
both aiming to reduce the risk surface associated with blindly trusting
'the RPKI Roots'.

In the RPKI hierarchical structure, a Trust Anchor (a root) is an
authority for which trust is assumed and not derived. The phrase
"assumed trust" means that violation of that trust is out-of-scope for
the threat model. On the other hand, the phrase "derived trust" refers
to trust automatically and securely computed with subjective logic. In
the context of the RPKI, trust is derived according to the rules for
validation of RPKI Certificates and Signed Objects.

One initiative is to impose 'locally configured constraints' which limit
the effective signing authority of an RIR. The other initiative is to
instantiate a sixth RPKI trust anchor - which chains up to the existing
RIR-operated infrastructure - and impose inter-RIR consensus-driven
constraints on that arc.

Initiative #1 - operator imposed constraints:
Cover letter & discussion: 
https://mailman.nanog.org/pipermail/nanog/2023-September/223354.html
Running code - rpki-client 8.7 & higher
https://cdn.openbsd.org/pub/OpenBSD/rpki-client/rpki-client-8.7.txt
An internet-draft detailing the implementation:

https://datatracker.ietf.org/doc/html/draft-snijders-constraining-rpki-trust-anchors

Initiative #2 - externally imposed constraints:
Cover letter: 
https://labs.apnic.net/index.php/2023/12/13/models-of-trust-in-the-rpki/
Running code: https://labs.apnic.net/nro-ta/
A proposal for the validation algorithm to be less rigid & more robust:

https://datatracker.ietf.org/doc/html/draft-spaghetti-sidrops-rpki-validation-update

I personally don't care much *who* imposes constraints, but at the
end of the day - someone's gotta do it. Keep watching this space!


SIDROPS - Working Group developments
===

Some quick updates from the IETF working group responsible for

Re: Sufficient Buffer Sizes

[Dale W. Carder]

Thus spake Mike Hammett (na...@ics-il.net) on Tue, Jan 02, 2024 at 05:02:22PM 
-0600:
> While attempting to ascertain how big of switch buffers I needed in a 100G 
> switch, I rediscovered this article where I first learned about switch 
> buffers.
> 
> https://fasterdata.es.net/network-tuning/router-switch-buffer-size-issues/#:~:text=Optimum%20Buffer%20Size=The%20general%20rule%20of%20thumb,1G%20host%20across%20the%20WAN.
> 
> It suggests that 60 meg is what you need at 10G. Is that per interface? Would 
> it be linear in that I would need 600 meg at 100G?

We've tried to be clear about the use cases where these guidelines
apply.  In these sets of articles, we are primarily describing issues
prevalent between many scientific research and education environments
where traffic can be dominated by multiplexing a low number of high-BDP
machine-machine flows, such as from a telescope array to a supercomputer
one continent away.  

Numbers here are not one-size-fits all, and are not necessarily
characteristic of what you would want to do for multiplexing say a
bazillion flows from cdns to homes all within ~10ms rtt.  That said, if
you dig in and understand where the numbers are coming from, the
principles apply.

Dale

Rackspace contact

[Nathan Book via NANOG]

Can someone at Rackspace contact me off list? We have issues reaching a
Rackspace customer's site.

Thanks,

*Nathan Book* | IT/Broadband Specialist | GMN Broadband

Re: Sufficient Buffer Sizes

[Maurice Brown]

Threads like this are why I subscribe to this.

On Wed, Jan 3, 2024 at 12:27 AM Saku Ytti  wrote:

> On Wed, 3 Jan 2024 at 01:05, Mike Hammett  wrote:
>
> > It suggests that 60 meg is what you need at 10G. Is that per interface?
> Would it be linear in that I would need 600 meg at 100G?
>
> Not at all.
>
> You need to understand WHY buffering is needed, to determine how much
> you want to offer buffering.
>
> Big buffering is needed, when:
>- Sender is faster than Receiver
>- Receiver wants to receive single flow at maximum rate
>- Sender is sending window growth at sender-rate, instead of
> estimated receiver-rate (Common case, but easy to change, as Linux
> already estimates receiver-rate, and 'tc' command can change this
> behaviour)
>
> Amount of big buffering depends on:
> - How much can the window grow, when it grows. Windows grow
> exponentially, so you need (RTT*receiver-rate)/2, /2 because if the
> window grows the first half is already done and is dropping in at
> receiver-rate, as ACKs come by.
>
>
> Let's imagine your sender is 100GE connected, and your receiver is
> 10GE connected. And you want to achieve a 10Gbps single flow rate.
>
> 10ms RTT - 12.5MB window size, worst case you need to grow 6.25MB and
> -10% off, because some of the growth you can send to the receiver,
> instead of buffering all of the growth, so you'd need 5.5-6MB.
> 100ms RTT would be ~60MB
> 200ms RTT would be ~600MB
>
>
> Now decide the answer you want to give in your products for these. At
> what RTT you want to guarantee what single-flow maximum rate?
>
> I do believe many of the CDNs are already using estimated
> receiver-rate to grow windows, which basically removes the need for
> buffering. But any standard cubic without tuning (i.e. all OS) will
> burst at line-rate window growth, causing the need for buffering.
>
> --
>   ++ytti
>

Re: Sufficient Buffer Sizes

[Saku Ytti]

On Wed, 3 Jan 2024 at 01:05, Mike Hammett  wrote:

> It suggests that 60 meg is what you need at 10G. Is that per interface? Would 
> it be linear in that I would need 600 meg at 100G?

Not at all.

You need to understand WHY buffering is needed, to determine how much
you want to offer buffering.

Big buffering is needed, when:
   - Sender is faster than Receiver
   - Receiver wants to receive single flow at maximum rate
   - Sender is sending window growth at sender-rate, instead of
estimated receiver-rate (Common case, but easy to change, as Linux
already estimates receiver-rate, and 'tc' command can change this
behaviour)

Amount of big buffering depends on:
- How much can the window grow, when it grows. Windows grow
exponentially, so you need (RTT*receiver-rate)/2, /2 because if the
window grows the first half is already done and is dropping in at
receiver-rate, as ACKs come by.


Let's imagine your sender is 100GE connected, and your receiver is
10GE connected. And you want to achieve a 10Gbps single flow rate.

10ms RTT - 12.5MB window size, worst case you need to grow 6.25MB and
-10% off, because some of the growth you can send to the receiver,
instead of buffering all of the growth, so you'd need 5.5-6MB.
100ms RTT would be ~60MB
200ms RTT would be ~600MB


Now decide the answer you want to give in your products for these. At
what RTT you want to guarantee what single-flow maximum rate?

I do believe many of the CDNs are already using estimated
receiver-rate to grow windows, which basically removes the need for
buffering. But any standard cubic without tuning (i.e. all OS) will
burst at line-rate window growth, causing the need for buffering.

-- 
  ++ytti