Paging AS13335/Cloudflare to the courtesy phone

2023-09-07 Thread Jim Popovitch via NANOG 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Why are you sending me this crap...please stop.  I've reached out to your NOC 
to no avail. 


Sep  7 19:11:19 web4.domainmail.net nginx: 172.68.1.193 - _ "POST 
/dms2/services2/ServerMMS2 HTTP/2.0" 400 150 "-" "Agent-Probe"
Sep  7 19:11:19 web4.domainmail.net nginx: 172.68.1.193 - _ "POST 
/dms2/services2/ServerMMS2 HTTP/2.0" 400 150 "-" "Agent-Probe"
Sep  7 19:11:19 web4.domainmail.net nginx: 172.68.1.161 - _ "POST 
/dms2/services2/ServerII2 HTTP/2.0" 400 150 "-" "Mozilla/5.0 (Windows NT 10.0; 
Win64; compatible) MSPAnywhere/7.50.0.1500"
Sep  7 19:11:19 web4.domainmail.net nginx: 172.68.170.148 - _ "POST 
/dms2/services2/ServerMMS2 HTTP/2.0" 400 150 "-" "Agent-Probe"
Sep  7 19:11:19 web4.domainmail.net nginx: 172.68.170.148 - _ "POST 
/dms2/services2/ServerMMS2 HTTP/2.0" 400 150 "-" "Agent-Probe"
Sep  7 19:11:19 web4.domainmail.net nginx: 172.68.1.153 - _ "POST /bosh/bosh/ 
HTTP/2.0" 400 150 "-" "-"
Sep  7 19:11:19 web4.domainmail.net nginx: 172.68.1.193 - _ "POST 
/dms2/services2/ServerMMS2 HTTP/2.0" 400 150 "-" "Agent-Probe"
Sep  7 19:11:20 web4.domainmail.net nginx: 172.71.142.51 - _ "POST 
/dms2/services2/ServerMMS2 HTTP/2.0" 400 150 "-" "Agent-Probe"
Sep  7 19:11:24 web4.domainmail.net nginx: 172.68.1.190 - _ "POST 
/dms2/services2/ServerMMS2 HTTP/2.0" 400 150 "-" "Agent-Probe"
Sep  7 19:11:24 web4.domainmail.net nginx: 172.68.1.196 - _ "POST /bosh/bosh/ 
HTTP/2.0" 400 150 "-" "-"
Sep  7 19:11:24 web4.domainmail.net nginx: 172.68.1.193 - _ "POST /bosh/bosh/ 
HTTP/2.0" 400 150 "-" "-"
Sep  7 19:11:24 web4.domainmail.net nginx: 172.68.1.193 - _ "POST /bosh/bosh/ 
HTTP/2.0" 400 150 "-" "-"
Sep  7 19:11:24 web4.domainmail.net nginx: 172.68.1.193 - _ "POST 
/dms2/services2/ServerMMS2 HTTP/2.0" 400 150 "-" "Agent-Probe"
Sep  7 19:11:25 web4.domainmail.net nginx: 172.68.1.130 - _ "POST 
/dms2/services2/ServerII2 HTTP/2.0" 400 150 "-" "Mozilla/5.0 (Windows NT 10.0; 
Win64; compatible) MSPAnywhere/7.50.0.1500"
Sep  7 19:11:26 web4.domainmail.net nginx: 172.68.1.196 - _ "POST 
/dms2/services2/ServerMMS2 HTTP/2.0" 400 150 "-" "Agent-Probe"
Sep  7 19:11:26 web4.domainmail.net nginx: 172.68.1.143 - _ "POST 
/dms2/services2/ServerMMS2 HTTP/2.0" 400 150 "-" "Agent-Probe"
Sep  7 19:11:29 web4.domainmail.net nginx: 172.68.1.196 - _ "POST /bosh/bosh/ 
HTTP/2.0" 400 150 "-" "-"
Sep  7 19:11:29 web4.domainmail.net nginx: 172.69.214.218 - _ "POST 
/dms2/services2/ServerMMS2 HTTP/2.0" 400 150 "-" "Agent-Probe"
Sep  7 19:11:29 web4.domainmail.net nginx: 172.69.214.218 - _ "POST 
/dms2/services2/ServerMMS2 HTTP/2.0" 400 150 "-" "Agent-Probe"
Sep  7 19:11:30 web4.domainmail.net nginx: 172.68.1.193 - _ "POST 
/dms2/services2/ServerMMS2 HTTP/2.0" 400 150 "-" "Agent-Probe"
Sep  7 19:11:30 web4.domainmail.net nginx: 172.68.1.174 - _ "POST 
/dms2/services2/ServerMMS2 HTTP/2.0" 400 150 "-" "Agent-Probe"
Sep  7 19:11:31 web4.domainmail.net nginx: 172.71.142.51 - _ "POST 
/dms2/services2/ServerMMS2 HTTP/2.0" 400 150 "-" "Agent-Probe"
Sep  7 19:11:31 web4.domainmail.net nginx: 172.71.142.51 - _ "POST 
/dms2/services2/ServerMMS2 HTTP/2.0" 400 150 "-" "Agent-Probe"
Sep  7 19:11:31 web4.domainmail.net nginx: 172.68.1.193 - _ "POST 
/dms2/services2/ServerMMS2 HTTP/2.0" 400 150 "-" "Agent-Probe"
Sep  7 19:11:33 web4.domainmail.net nginx: 172.71.147.97 - _ "POST 
/dms2/services2/ServerMMS2 HTTP/2.0" 400 150 "-" "Agent-Probe"

Thanks!

- -Jim P.
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEE3RmV4WutJ2KyCS2zPcxbabkKGJ8FAmT6ITUACgkQPcxbabkK
GJ캜㿽▊둳Ձ誣䎋풑䣡ꠓ첉∽蹞ያ㥲㳧䆁೓納淚ꥐ
uAYHRLMZXaaUBgpa0qTWQwꞻ㩐鐯픿䄉ϊ⌋揪핅뛍혦턔綻䧻薱
aOF04nym5EooMRE2CNz8Hlt8Axa깚瘷⺠䵻믰둥�耿懊댒㤌踇
jdrbRチ娳齢暰熷毉쫮ꈚ⧎Ņ屎䠬ᾟ롤뫣ﵠ��
Z6uWPaoLivGkviLaVUXWxecDulOIsQkNs5k9UUUq8CgMRRJox9RYu369zIqUNAuX
N9xCl3IFQZ0Kl50wmbf8ajjI0swfh971jqeAIto8xEAgF66Iy3ty4nPEqTZjr/gv
YZAjNa1UCkXKyyXHPuYWZC4bMaxvQACVsG2h1siylDmDB236Wr6OSMvys9q16SHd
t2837hXJOpVlNwlKAapZQMs35⺒㗑鋉耶櫩簀ﺻ㾐뚳㽼
rctyoCqv蔤翝퉁㞸윱铴ද夙Ꟃ翭몏쒌쏹았Ɬꘝ跅亿
AvSaXSP5iWG3NJWpUVgbU5GKpJp24c닩ᱷ尬鉁庑姎험඾䱞遼኷
O䯒ﮅꆿ묧ힵ龚ꉟ袀曼芆㍂坡槳痟=
=ldq2
-END PGP SIGNATURE-

Re: Guest Column: Kentik's Doug Madory, Last Call for Upcoming ISOC Course + More

2023-09-07 Thread Anne Mitchell 



> On Sep 7, 2023, at 10:25 AM, Randy Bush  wrote:
> 
>> *READ MORE
>> Last
> 
> can we please get URLs without all the invasive tracking?

list-manage.com is Mailchimp; not sure it's possible to turn off tracking when 
using an ESP like that. :-(

Anne

-- 
Anne P. Mitchell
Attorney at Law
Email Law & Policy Attorney
CEO Institute for Social Internet Public Policy (ISIPP)
Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal email marketing law)
Author: The Email Deliverability Handbook
Board of Directors, Denver Internet Exchange
Dean Emeritus, Cyberlaw & Cybersecurity, Lincoln Law School
Prof. Emeritus, Lincoln Law School
Chair Emeritus, Asilomar Microcomputer Workshop
Counsel Emeritus, eMail Abuse Prevention System (MAPS)

Re: Guest Column: Kentik's Doug Madory, Last Call for Upcoming ISOC Course + More

2023-09-07 Thread Randy Bush 
> *READ MORE
> Last

can we please get URLs without all the invasive tracking?

randy

[NANOG-announce] Guest Column: Kentik's Doug Madory, Last Call for Upcoming ISOC Course + More

2023-09-07 Thread Nanog News 
*Guest Column: Kentik's Doug Madory*
*BGP Incidents: From Traffic-Disrupting BGP Leaks to Crypto-Stealing BGP
Hijacks*

BGP routing incidents can be problematic for a range of reasons. In some
cases, they simply disrupt the flow of legitimate internet traffic while in
others, they can result in the misdirection of communications, posing a
security risk from interception or manipulation.





*READ MORE
Last
Call for Upcoming ISOC Course: 11 Sept. *
*Fundamentals of Designing and Deploying Computer Networks*
This course will discuss the fundamentals of networking, Ethernet, and WIFI
technologies. It will additionally teach the planning, design, and
deployment of simple LANs and cover how to connect a LAN to the Internet.

*LEARN MORE
*

*Reminder: Board Nominations are Open! *
*Your Choice, Your Vote*

*Elections: 2023*

The NANOG Board of Directors is an active and engaged part of NANOG. The
Board is responsible for and works closely with committees to promote,
support, and improve NANOG.


*VIEW MORE
*
*What's Trending on the Mailing List? *
*Find a Solution Via our Community Forum Online Discussion Boards *

Remember you must log in or create an account to access the Community
Forum.*

Lossy cogent p2p experiences?
Replies: 62

JunOS/FRR/Nokia et al BGP critical issue   Replies: 13

Re: Destination Preference Attribute for BGP  Replies: 20

v6 route mess frm AS266970
Replies: 5


*VIEW MORE  *
*Video of the Week *

*The Future is Now: Delivering the Next Generation Brilliant Network*
Brilliant networks delivering next-generation connected experiences are
here.

Comcast Chief Network Officer Elad Nafshi will share how 10G network
technologies are evolving related experiences in real-time, even as they
continue to get more innovative, faster, reliable, and secure for future
generations.

*WATCH NOW * 
___
NANOG-announce mailing list
NANOG-announce@nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog-announce

Guest Column: Kentik's Doug Madory, Last Call for Upcoming ISOC Course + More

2023-09-07 Thread Nanog News 
*Guest Column: Kentik's Doug Madory*
*BGP Incidents: From Traffic-Disrupting BGP Leaks to Crypto-Stealing BGP
Hijacks*

BGP routing incidents can be problematic for a range of reasons. In some
cases, they simply disrupt the flow of legitimate internet traffic while in
others, they can result in the misdirection of communications, posing a
security risk from interception or manipulation.





*READ MORE
Last
Call for Upcoming ISOC Course: 11 Sept. *
*Fundamentals of Designing and Deploying Computer Networks*
This course will discuss the fundamentals of networking, Ethernet, and WIFI
technologies. It will additionally teach the planning, design, and
deployment of simple LANs and cover how to connect a LAN to the Internet.

*LEARN MORE
*

*Reminder: Board Nominations are Open! *
*Your Choice, Your Vote*

*Elections: 2023*

The NANOG Board of Directors is an active and engaged part of NANOG. The
Board is responsible for and works closely with committees to promote,
support, and improve NANOG.


*VIEW MORE
*
*What's Trending on the Mailing List? *
*Find a Solution Via our Community Forum Online Discussion Boards *

Remember you must log in or create an account to access the Community
Forum.*

Lossy cogent p2p experiences?
Replies: 62

JunOS/FRR/Nokia et al BGP critical issue   Replies: 13

Re: Destination Preference Attribute for BGP  Replies: 20

v6 route mess frm AS266970
Replies: 5


*VIEW MORE  *
*Video of the Week *

*The Future is Now: Delivering the Next Generation Brilliant Network*
Brilliant networks delivering next-generation connected experiences are
here.

Comcast Chief Network Officer Elad Nafshi will share how 10G network
technologies are evolving related experiences in real-time, even as they
continue to get more innovative, faster, reliable, and secure for future
generations.

*WATCH NOW *

Re: Lossy cogent p2p experiences?

2023-09-07 Thread Masataka Ohta 

Saku Ytti wrote:


And you will be wrong. Packet arriving out of order, will be
considered previous packet lost by host, and host will signal need for
resend.


As I already quote the very old and fundamental paper on
the E2E argument:

End-To-End Arguments in System Design

https://groups.csail.mit.edu/ana/Publications/PubPDFs/End-to-End%20Arguments%20in%20System%20Design.pdf
: 3.4 Guaranteeing FIFO Message Delivery

and as is described in rfc2001,

   Since TCP does not know whether a duplicate ACK is caused by a lost
   ^^^
   segment or just a reordering of segments, it waits for a small number
   ^
   of duplicate ACKs to be received.  It is assumed that if there is
   just a reordering of the segments, there will be only one or two
   duplicate ACKs before the reordered segment is processed, which will
   then generate a new ACK.  If three or more duplicate ACKs are
 ^^^
   received in a row, it is a strong indication that a segment has been
   
   lost.
   -

in networking, it is well known that "Guaranteeing FIFO Message
Delivery" by the network is impossible because packets arriving
out of order without packet losses is inevitable and is not
uncommon.

As such, slight reordering is *NOT* interpreted as previous
packet loss.

The allowed amount of reordering depends on TCP implementations
and can be controlled by upgrading TCP.

Masataka Ohta

Re: Lossy cogent p2p experiences?

2023-09-07 Thread Saku Ytti 
On Thu, 7 Sept 2023 at 15:45, Benny Lyne Amorsen
 wrote:

> Juniper's solution will cause way too much packet reordering for TCP to
> handle. I am arguing that strict round-robin load balancing will
> function better than hash-based in a lot of real-world
> scenarios.

And you will be wrong. Packet arriving out of order, will be
considered previous packet lost by host, and host will signal need for
resend.

-- 
  ++ytti

Re: Lossy cogent p2p experiences?

2023-09-07 Thread Masataka Ohta 

Tom Beecher wrote:


Well, not exactly the same thing. (But it's my mistake, I was referring to
L3 balancing, not L2 interface stuff.)


That should be a correct referring.


load-balance per-packet will cause massive reordering,


If buffering delay of ECM paths can not be controlled , yes.


because it's random
spray , caring about nothing except equal loading of the members.


Equal loading on point to point links between two routers by
(weighted) round robin means mostly same buffering delay, which
won't cause massive reordering.

Masataka Ohta

Re: Lossy cogent p2p experiences?

2023-09-07 Thread Benny Lyne Amorsen 
Mark Tinka  writes:

>     set interfaces ae2 aggregated-ether-options load-balance per-packet
>
> I ran per-packet on a Juniper LAG 10 years ago. It produced 100%
> perfect traffic distribution. But the reordering was insane, and the
> applications could not tolerate it.

Unfortunately that is not strict round-robin load balancing. I do not
know about any equipment that offers actual round-robin
load-balancing.

Juniper's solution will cause way too much packet reordering for TCP to
handle. I am arguing that strict round-robin load balancing will
function better than hash-based in a lot of real-world
scenarios.

Re: Lossy cogent p2p experiences?

2023-09-07 Thread Saku Ytti 
On Thu, 7 Sept 2023 at 00:00, David Bass  wrote:

> Per packet LB is one of those ideas that at a conceptual level are great, but 
> in practice are obvious that they’re out of touch with reality.  Kind of like 
> the EIGRP protocol from Cisco and using the load, reliability, and MTU 
> metrics.

Those multi metrics are in ISIS as well (if you don't use wide). And I
agree those are not for common cases, but I wouldn't be shocked if
someone has legitimate MTR use-case where different metric-type
topologies are very useful. But as long as we keep context as the
Internet, true.

100% reordering does not work for the Internet, not without changing
all end hosts. And by changing those, it's not immediately obvious how
we end-up in better place, like if we wait bit longer to signal
packet-loss, likely we end up in worse place, as reordering just is so
dang rare today, because congestion control choices have made sure no
one reorders, or customers will yell at you, yet packet-loss remains
common.
Perhaps if congestion control used latency or FEC instead of loss, we
could tolerate reordering while not underperforming under loss, but
I'm sure in decades following that decision we'd learn new ways how we
don't understand any of this.

But for non-internet applications, where you control hosts, per-packet
is used and needed, I think HPC applications, and GPU farms etc. are
the users who asked JNPR to implement this.



-- 
  ++ytti