Re: Increase bandwidth usage in partial-mesh network?

[Karsten Thomann via NANOG]

  I would agree.Not sure if other vendors have something similar, but in Juniper land you could use traffic engineering with container lsp to go a step further than just plain rsvp-te.Kind regards Karsten Von: nanog@nanog.orgGesendet: 14. Oktober 2021 03:06An: athomp...@merlin.mb.caAntworten: mrodrig...@fletnet.comCc: nanog@nanog.orgBetreff: Re: Increase bandwidth usage in partial-mesh network?  Assuming that the reasons for the low bandwidth and use of radio is due to physical constraints - distances, inhospitable terrain between nodes, etc.  In this case, some good 'ol MPLS traffic engineering using LSP's with bandwidth reservations may be the way to influence how traffic is routed.  Then, they may need some platform to provide observability and potentially dynamic re-routing of LSP's based on actual or predicted congestion situations.  If traffic patterns and utilization are not ideally deterministic, then skip the bandwidth reservation and ensure that the automation is in place to reroute traffic when necessary.I know, adding complexity, but if you just can't build the links you would want, this may be a way to work with what you've got.Best Regards,Mauricio RodriguezFounder / OwnerFletnet Network Engineering (www.fletnet.com)Follow us on LinkedInmauricio.rodrig...@fletnet.comOffice: +1 786-309-1082Direct: +1 786-309-5493On Wed, Oct 13, 2021 at 1:33 PM Adam Thompson  wrote:






Looking for recommendtions or suggestions...




I've got a downstream customer asking for help;  they have a private internal network that I've taken to calling the "partial-mesh network from hell": it's got two partially-overlapping radio networks, mixed with islands of isolated fiber connectivity.

Dynamic routing protocols (IS-IS, OSPF, EIGRP, etc.) generally will only select the _best_ path, they won't spread the load unless all paths are equal - and they are very unequal in this network, ECMP would likely fail horribly.


The network is becoming bandwidth-limited, so they're wanting to make use of all available paths, not just the single "best" path.  It's also remote and spread out, so adding new links or upgrading existing links is difficult and expensive.

Oh, and their routers are overdue for a refresh, so acquiring replacement h/w is now possible.





Has anyone come across any product or technology that can handle the multi-path-ness and the private-network-ness like a regular router, but also provides the intelligent per-flow path steering based on e.g. latency, like an SD-WAN device (and/or some firewalls)?




Here's hoping,


-Adam








Adam Thompson
Consultant, Infrastructure Services

100 - 135 Innovation Drive
Winnipeg, MB, R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
athomp...@merlin.mb.ca
www.merlin.mb.ca









This message (and any associated files) may contain confidential and/or privileged information. If you are not the intended recipient or authorized to receive this for the intended recipient, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by sending a reply e-mail and delete this message. Thank you for your cooperation.

Re: Increase bandwidth usage in partial-mesh network?

[Mauricio Rodriguez via NANOG]

Assuming that the reasons for the low bandwidth and use of radio is due to
physical constraints - distances, inhospitable terrain between nodes, etc.
In this case, some good 'ol MPLS traffic engineering using LSP's with
bandwidth reservations may be the way to influence how traffic is routed.
Then, they may need some platform to provide observability and potentially
dynamic re-routing of LSP's based on actual or predicted congestion
situations.  If traffic patterns and utilization are not ideally
deterministic, then skip the bandwidth reservation and ensure that the
automation is in place to reroute traffic when necessary.

I know, adding complexity, but if you just can't build the links you would
want, this may be a way to work with what you've got.

Best Regards,

Mauricio Rodriguez

Founder / Owner

Fletnet Network Engineering (www.fletnet.com)
*Follow us* on LinkedIn 

mauricio.rodrig...@fletnet.com

Office: +1 786-309-1082

Direct: +1 786-309-5493



On Wed, Oct 13, 2021 at 1:33 PM Adam Thompson 
wrote:

> Looking for recommendtions or suggestions...
>
> I've got a downstream customer asking for help;  they have a private
> internal network that I've taken to calling the "partial-mesh network from
> hell": it's got two partially-overlapping radio networks, mixed with
> islands of isolated fiber connectivity.
> Dynamic routing protocols (IS-IS, OSPF, EIGRP, etc.) generally will only
> select the _best_ path, they won't spread the load unless all paths are
> equal - and they are very unequal in this network, ECMP would likely fail
> horribly.
> The network is becoming bandwidth-limited, so they're wanting to make use
> of all available paths, not just the single "best" path.  It's also remote
> and spread out, so adding new links or upgrading existing links is
> difficult and expensive.
> Oh, and their routers are overdue for a refresh, so acquiring replacement
> h/w is now possible.
>
> Has anyone come across any product or technology that can handle the
> multi-path-ness and the private-network-ness like a regular router, but
> also provides the intelligent per-flow path steering based on e.g. latency,
> like an SD-WAN device (and/or some firewalls)?
>
> Here's hoping,
> -Adam
>
> *Adam Thompson*
> Consultant, Infrastructure Services
> [image: 1593169877849]
> 100 - 135 Innovation Drive
> Winnipeg, MB, R3T 6A8
> (204) 977-6824 or 1-800-430-6404 (MB only)
> athomp...@merlin.mb.ca
> www.merlin.mb.ca
>

-- 
This message (and any associated files) may contain confidential and/or 
privileged information. If you are not the intended recipient or authorized 
to receive this for the intended recipient, you must not use, copy, 
disclose or take any action based on this message or any information 
herein. If you have received this message in error, please advise the 
sender immediately by sending a reply e-mail and delete this message. Thank 
you for your cooperation.

Re: Increase bandwidth usage in partial-mesh network?

[Adam Thompson]

Hah, no not your client .  Their existing network is actually surprisingly 
stable, but it is bandwidth-constrained.  As well as the various other replies 
I've seen here and off-list (THANKS!), the only commercial product I've found 
so far that might have a hope of handling this is HPE/Aruba's Silverpeak line.  
We'll see what else comes out of the woodwork, though - if nothing else, it's a 
very interesting exercise!

Adam Thompson
Consultant, Infrastructure Services
[1593169877849]
100 - 135 Innovation Drive
Winnipeg, MB, R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
athomp...@merlin.mb.ca
www.merlin.mb.ca

From: Fletcher Kittredge 
Sent: October 13, 2021 12:59
To: Adam Thompson 
Cc: nanog 
Subject: Re: Increase bandwidth usage in partial-mesh network?


Hey! From the description it must be one of our clients!

Just beware if you go this route, a network that is probably already unstable 
and unreliable will become at least an order of magnitude worse. You can't fix 
ten lbs of stuff into a 4 lb stuff bag. The internet protocols do not tolerate 
congestion well.


On Wed, Oct 13, 2021 at 1:31 PM Adam Thompson 
mailto:athomp...@merlin.mb.ca>> wrote:
Looking for recommendtions or suggestions...

I've got a downstream customer asking for help;  they have a private internal 
network that I've taken to calling the "partial-mesh network from hell": it's 
got two partially-overlapping radio networks, mixed with islands of isolated 
fiber connectivity.
Dynamic routing protocols (IS-IS, OSPF, EIGRP, etc.) generally will only select 
the _best_ path, they won't spread the load unless all paths are equal - and 
they are very unequal in this network, ECMP would likely fail horribly.
The network is becoming bandwidth-limited, so they're wanting to make use of 
all available paths, not just the single "best" path.  It's also remote and 
spread out, so adding new links or upgrading existing links is difficult and 
expensive.
Oh, and their routers are overdue for a refresh, so acquiring replacement h/w 
is now possible.

Has anyone come across any product or technology that can handle the 
multi-path-ness and the private-network-ness like a regular router, but also 
provides the intelligent per-flow path steering based on e.g. latency, like an 
SD-WAN device (and/or some firewalls)?

Here's hoping,
-Adam

Adam Thompson
Consultant, Infrastructure Services
[1593169877849]
100 - 135 Innovation Drive
Winnipeg, MB, R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
athomp...@merlin.mb.ca
www.merlin.mb.ca


--
Fletcher Kittredge
GWI
207-602-1134
www.gwi.net

Re: Increase bandwidth usage in partial-mesh network?

[William Herrin]

On Wed, Oct 13, 2021 at 10:30 AM Adam Thompson  wrote:
> Has anyone come across any product or technology that can handle the 
> multi-path-ness and the private-network-ness like a regular router, but also 
> provides the intelligent per-flow path steering based on e.g. latency, like 
> an SD-WAN device (and/or some firewalls)?

The babel protocol does some of this.
https://datatracker.ietf.org/doc/html/rfc6126

Regards,
Bill Herrin

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

[NANOG-announce] NANOG 83: City Guide + Keynotes + More

[Nanog News]

A NANOG 83 Attendees' Guide to Minneapolis
Get ready to feel welcomed in the industrial landmark city, known as the
birthplace of iconic musicians, incredible museums, + the "Minnesota nice"

 culture.

Our next meeting, NANOG 83 (Nov. 1 - 3), will be located near the
breathtaking end of the Mississippi River in Minnesota.

When community members need a break from improving the Internet of
tomorrow, here is a list of the "best of the best" to experience in
Minneapolis.

Meet our Keynote Speakers
"Geeky Entrepreneur" + Government Intelligence Cybersecurity Pro

*Meet Bert Hubert:* Bert (@PowerDNS_Bertis) is the founder of PowerDNS, a
software that powers a significant fraction of the Internet. He also did
government cybersecurity work and co-founded a software company in that
field. These days, Bert does DNA research and is part of the governing
board regulating the Dutch intelligence and security agencies.

*Date:* Tuesday, Nov 2 at 10 am Central virtually, live Q
*Talk Title: *Who Controls the Internet? And Should They?

*Abstract of Presentation:*  This presentation discusses how control of the
internet experience is moving more and more into the hands of browser and
phone vendors. The advent of end-to-end encryption, also on control planes
and metadata like DNS, means that no one else can influence the Internet -
except in extremely heavy-handed and binary fashion...


Meet our Keynote Speakers
Chief Technology Officer & Vice President, Product Engineering &
Infrastructure

*Meet John Brzozowski: *@jjmbcom - Talks about #iot, #lorawan, and
#loraalliance. John is an executive technology leader with a deep
understanding of product development and infrastructure across multiple
industries and diverse product and service offerings.

*Date: *Wednesday, Nov 3 at 10 am Central virtually, live from the Grand
Lakes Ballroom.
*Talk Title: * IPv6 - The Next 10 years

*Abstract of Presentation: *World IPv6 Day was in 2011, World IPv6 Launch
in 2012. We will briefly reflect on the status of IPv6 deployment across
eyeball and content networks - 10 years later. We will take a look at
statistics across a wide range of public and private (cited) sources...

We Have Missed You!
Less than 3 Weeks until NANOG 83 - Register Now!

*Reunited, and it feels so good. *We cannot wait to see you in person
and/or virtually at NANOG 83 in less than three weeks! Complimentary
registration is available for those in need and virtual only.

*Have concerns about traveling during the pandemic?* Check out our Safety +
Travel Guide.  Time
is running out, don't miss all the incredible networking opportunities and
programming now.

Let's Hack!
Still, Time to Register for NANOG 83 Hybrid Hackathon

*There's still time! *Register for the Hackathon today. Virtual kick-off is
on Oct 22, + hacking is on Oct 30 - 31.

*Hackathons are an essential part of NANOG conferences,* designed to be
both fun and engaging. NANOG Hackathons are hands-on and educational at
their core — directly supporting the most critical aspects of our mission.
All levels are welcome to participate, and as always, registration is free.
___
NANOG-announce mailing list
NANOG-announce@nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog-announce

NANOG 83: City Guide + Keynotes + More

[Nanog News]

A NANOG 83 Attendees' Guide to Minneapolis
Get ready to feel welcomed in the industrial landmark city, known as the
birthplace of iconic musicians, incredible museums, + the "Minnesota nice"

 culture.

Our next meeting, NANOG 83 (Nov. 1 - 3), will be located near the
breathtaking end of the Mississippi River in Minnesota.

When community members need a break from improving the Internet of
tomorrow, here is a list of the "best of the best" to experience in
Minneapolis.

Meet our Keynote Speakers
"Geeky Entrepreneur" + Government Intelligence Cybersecurity Pro

*Meet Bert Hubert:* Bert (@PowerDNS_Bertis) is the founder of PowerDNS, a
software that powers a significant fraction of the Internet. He also did
government cybersecurity work and co-founded a software company in that
field. These days, Bert does DNA research and is part of the governing
board regulating the Dutch intelligence and security agencies.

*Date:* Tuesday, Nov 2 at 10 am Central virtually, live Q
*Talk Title: *Who Controls the Internet? And Should They?

*Abstract of Presentation:*  This presentation discusses how control of the
internet experience is moving more and more into the hands of browser and
phone vendors. The advent of end-to-end encryption, also on control planes
and metadata like DNS, means that no one else can influence the Internet -
except in extremely heavy-handed and binary fashion...


Meet our Keynote Speakers
Chief Technology Officer & Vice President, Product Engineering &
Infrastructure

*Meet John Brzozowski: *@jjmbcom - Talks about #iot, #lorawan, and
#loraalliance. John is an executive technology leader with a deep
understanding of product development and infrastructure across multiple
industries and diverse product and service offerings.

*Date: *Wednesday, Nov 3 at 10 am Central virtually, live from the Grand
Lakes Ballroom.
*Talk Title: * IPv6 - The Next 10 years

*Abstract of Presentation: *World IPv6 Day was in 2011, World IPv6 Launch
in 2012. We will briefly reflect on the status of IPv6 deployment across
eyeball and content networks - 10 years later. We will take a look at
statistics across a wide range of public and private (cited) sources...

We Have Missed You!
Less than 3 Weeks until NANOG 83 - Register Now!

*Reunited, and it feels so good. *We cannot wait to see you in person
and/or virtually at NANOG 83 in less than three weeks! Complimentary
registration is available for those in need and virtual only.

*Have concerns about traveling during the pandemic?* Check out our Safety +
Travel Guide.  Time
is running out, don't miss all the incredible networking opportunities and
programming now.

Let's Hack!
Still, Time to Register for NANOG 83 Hybrid Hackathon

*There's still time! *Register for the Hackathon today. Virtual kick-off is
on Oct 22, + hacking is on Oct 30 - 31.

*Hackathons are an essential part of NANOG conferences,* designed to be
both fun and engaging. NANOG Hackathons are hands-on and educational at
their core — directly supporting the most critical aspects of our mission.
All levels are welcome to participate, and as always, registration is free.

Re: verizon fios, northeast, routing issues?

[Miles Fidelman]

Ok folks,

Thanks for the info about uunet.  But that doesn't address:

3. The intermittent, high delays (factor of 10) jump out  (also, when 
running ping tests, there seem to be intermittent periods of long 
sequences of timeouts) 
or, that, for about 4 years now, gamers seem to be reporting really poor 
performance across FIOS in the Northeast - tied to rather high packet 
loss rates.


Note that those packet losses seems to be bursts of 8-10 lost packets 
every 10 packets or so, and the really high delays on some of the 
traceroutes seem to indicate that it's happening somewhere in the middle 
of the path, not at my end.


And, come to think of it, that might explain some of the horrid 
performance of the FIOS channel guide.



Any thoughts?  Anyone here from Verizon Northeast FIOS operations who 
might have a comment?


Thanks,

Miles Fidelman



Miles Fidelman wrote:

Any Verizon folks here?

I've been having some rather weird network issues lately - just 
reading email via IMAP, from home.  Over a 1gig FIOS connection to a 
machine in a nearby Tierpoint data center that has LOTS of good 
connectivity.


I just tried some traceroutes, and got some interesting results:

These originate on a machine connected to a 1gig FIOS feed, and end at 
a machine, located in a Tierpoint datacenter, about 10 miles from here.


traceroute to ntcorp.com (207.154.13.58), 64 hops max, 52 byte packets
 1  * fios_quantum_gateway (192.168.1.1)  3.530 ms  2.822 ms
 2  * * *
 3  100.41.27.110 (100.41.27.110)  14.970 ms  5.323 ms  6.306 ms
 4  0.csi1.bstnmafr-mse01-bb-su1.alter.net (140.222.10.32)  11.069 ms  
8.477 ms  17.097 ms

 5  * * *
 6  0.ae1.br1.bos30.alter.net (140.222.236.253)  17.121 ms  19.027 ms
    0.ae2.br1.bos30.alter.net (140.222.236.255)  19.795 ms
 7  * * *
 8  colo4-dalla.bear1.boston1.level3.net (4.53.61.86)  2205.648 ms 
8.331 ms  13.161 ms

 9  static-33-65-203-66.axsne.net (66.203.65.33)  16.951 ms 13.791 ms
    static-145-65-203-66.axsne.net (66.203.65.145)  21.503 ms
10  server1.ntcorp.com (207.154.13.58)  17.872 ms  15.902 ms 14.415 ms

Several things jump out:

1. alter.net is not a common path between here & there - usually a 
lower grade connection, when other backbones aren't working right


2. origin - alter.net - level.3 - endpoint is just bizarre, one would 
think that the regional FIOS network has a direct connection to 
level.3  (it also seems kind of odd that the packets are flowing from 
Acton MA, to Boston, and back out to Marlboro MA - there's an awful 
lot of fiber running along Rt. 495, and the networks are fairly dense 
around here)


3. The intermittent, high delays (factor of 10) jump out  (also, when 
running ping tests, there seem to be intermittent periods of long 
sequences of timeouts)


All in all it's really mucking with both streaming services, and 
simply posting emails (SMTP timeouts).


All of which leads me to wonder if there's something mucked up with 
Verizon's routing tables (or a particular network interface).


Any insights (or fixes) to be had?

Thanks,

Miles Fidelman






--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

Theory is when you know everything but nothing works.
Practice is when everything works but no one knows why.
In our lab, theory and practice are combined:
nothing works and no one knows why.  ... unknown

Re: DNS pulling BGP routes?

[Jay Hennigan]

On 10/13/21 07:34, Masataka Ohta wrote:


But, I certainly mean that CDN operators should not request
peering directly to access/retail ISPs merely because they have
their own transit, because the transit is not at all neutral.


I'm not sure that I understand this. Peering is rarely if ever neutral. 
It's almost always "My network and customers only to your network and 
customers only."


CDNs and their customers (content providers) peering with ISPs and their 
customers (eyeballs) seems to me to be a win-win.


Access/retail ISPs should want to peer with CDNs as it greatly reduces 
their transport costs. CDNs will want to peer with access/retail ISPs 
for the same reason.


Specifically what is the objection to CDNs peering with access ISPs?

--
Jay Hennigan - j...@west.net
Network Engineering - CCIE #7880
503 897-8550 - WB6RDV

Re: Increase bandwidth usage in partial-mesh network?

[Mark Tinka]

On 10/13/21 19:59, Fletcher Kittredge wrote:



Hey! From the description it must be one of our clients!

Just beware if you go this route, a network that is probably already 
unstable and unreliable will become at least an order of magnitude 
worse. You can't fix ten lbs of stuff into a 4 lb stuff bag. The 
internet protocols do not tolerate congestion well.


It sounds like they need to get back to the basics first.

Simplification, in lieu of added complexity, seems to be the appealing 
approach.


Mark.

Re: Increase bandwidth usage in partial-mesh network?

[Fletcher Kittredge]

Hey! From the description it must be one of our clients!

Just beware if you go this route, a network that is probably already
unstable and unreliable will become at least an order of magnitude worse.
You can't fix ten lbs of stuff into a 4 lb stuff bag. The internet
protocols do not tolerate congestion well.


On Wed, Oct 13, 2021 at 1:31 PM Adam Thompson 
wrote:

> Looking for recommendtions or suggestions...
>
> I've got a downstream customer asking for help;  they have a private
> internal network that I've taken to calling the "partial-mesh network from
> hell": it's got two partially-overlapping radio networks, mixed with
> islands of isolated fiber connectivity.
> Dynamic routing protocols (IS-IS, OSPF, EIGRP, etc.) generally will only
> select the _best_ path, they won't spread the load unless all paths are
> equal - and they are very unequal in this network, ECMP would likely fail
> horribly.
> The network is becoming bandwidth-limited, so they're wanting to make use
> of all available paths, not just the single "best" path.  It's also remote
> and spread out, so adding new links or upgrading existing links is
> difficult and expensive.
> Oh, and their routers are overdue for a refresh, so acquiring replacement
> h/w is now possible.
>
> Has anyone come across any product or technology that can handle the
> multi-path-ness and the private-network-ness like a regular router, but
> also provides the intelligent per-flow path steering based on e.g. latency,
> like an SD-WAN device (and/or some firewalls)?
>
> Here's hoping,
> -Adam
>
> *Adam Thompson*
> Consultant, Infrastructure Services
> [image: 1593169877849]
> 100 - 135 Innovation Drive
> Winnipeg, MB, R3T 6A8
> (204) 977-6824 or 1-800-430-6404 (MB only)
> athomp...@merlin.mb.ca
> www.merlin.mb.ca
>


-- 
Fletcher Kittredge
GWI
207-602-1134
www.gwi.net

Increase bandwidth usage in partial-mesh network?

[Adam Thompson]

Looking for recommendtions or suggestions...

I've got a downstream customer asking for help;  they have a private internal 
network that I've taken to calling the "partial-mesh network from hell": it's 
got two partially-overlapping radio networks, mixed with islands of isolated 
fiber connectivity.
Dynamic routing protocols (IS-IS, OSPF, EIGRP, etc.) generally will only select 
the _best_ path, they won't spread the load unless all paths are equal - and 
they are very unequal in this network, ECMP would likely fail horribly.
The network is becoming bandwidth-limited, so they're wanting to make use of 
all available paths, not just the single "best" path.  It's also remote and 
spread out, so adding new links or upgrading existing links is difficult and 
expensive.
Oh, and their routers are overdue for a refresh, so acquiring replacement h/w 
is now possible.

Has anyone come across any product or technology that can handle the 
multi-path-ness and the private-network-ness like a regular router, but also 
provides the intelligent per-flow path steering based on e.g. latency, like an 
SD-WAN device (and/or some firewalls)?

Here's hoping,
-Adam

Adam Thompson
Consultant, Infrastructure Services
[1593169877849]
100 - 135 Innovation Drive
Winnipeg, MB, R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
athomp...@merlin.mb.ca
www.merlin.mb.ca

Re: DNS pulling BGP routes?

[Mark Tinka]

On 10/13/21 17:24, Masataka Ohta wrote:



The problem is that, unlike neutral transit providers, "the bits"
is biased by the CDN provider.

Then, access/retail ISPs who also want to supply their own contents,
even though they must be neutral to contents provided by neutral
transit providers, naturally refuse peering with the anti-neutral
CDN providers.

Remember that CDN providers are not neutral at all.


Well, the purpose of a network is whatever its proprietor deems it to 
be, and makes no false advertising about it.


A private enterprise network that carries a company's internal traffic - 
which may or may not interface with an external network that is 
interested in some or all of that traffic - would, in your eyes, be 
classified as not neutral, because it chooses not to use its network to 
provide global IP Transit?


In my mind, the word "transit" refers to carriage between two 
non-homogeneous points. So network A (customer) will talk to network C 
(content) via my network B (transit). If the traffic originates either 
from A or C, BUT terminates/ends inside of B, I do not consider that 
transit.


I'm unaware of content operators who run their own network and (promise 
to) provide connectivity between A and C.


Mark.

Re: DNS pulling BGP routes?

[Masataka Ohta]

Tom Beecher wrote:


But, I certainly mean that CDN operators should not request
peering directly to access/retail ISPs merely because they have
their own transit, because the transit is not at all neutral.



I'm still confused.

Let's say I have a CDN network, with a datacenter somewhere, an edge site
somewhere else. I carry my bits from my datacenter, across my internal
network, to my edge site. This is where I intend to hand the bits over to
someone else to carry them to the end user.


The problem is that, unlike neutral transit providers, "the bits"
is biased by the CDN provider.

Then, access/retail ISPs who also want to supply their own contents,
even though they must be neutral to contents provided by neutral
transit providers, naturally refuse peering with the anti-neutral
CDN providers.

Remember that CDN providers are not neutral at all.

Masataka Ohta

Re: DNS pulling BGP routes?

[Christopher Morrow]

On Wed, Oct 13, 2021 at 10:56 AM Tom Beecher  wrote:

> But, I certainly mean that CDN operators should not request
>> peering directly to access/retail ISPs merely because they have
>> their own transit, because the transit is not at all neutral.
>>
>
> I'm still confused.
>
> Let's say I have a CDN network, with a datacenter somewhere, an edge site
> somewhere else. I carry my bits from my datacenter, across my internal
> network, to my edge site. This is where I intend to hand the bits over to
> someone else to carry them to the end user.
>
> Let's say in this site, I have a paid transit connection , and a peering
> session directly with the end user's ISP. Where is anything related to
> neutrality being 'violated', regardless of which path I choose to send the
> bits out?
>
>
It sounds like masataka is saying that the network between your
'datacenter' and 'cdn node' is a 'transit network'.
I think 'transit network' is a sentence fragment much like: "bgp peer" ..
it's overloaded (in this conversation at least)
so probably some more clarity is required in the conversation to progress
in a meaningful manner.


> On Wed, Oct 13, 2021 at 10:36 AM Masataka Ohta <
> mo...@necom830.hpcl.titech.ac.jp> wrote:
>
>> Tom Beecher wrote:
>>
>> >> For network neutrality, backbone providers *MUST* be neutral
>> >> for contents they carry.
>> >>
>> >> However, CDN providers having their own backbone are using
>> >> their backbone for contents they prefer, which is *NOT*
>> >> neutral at all.
>> >>
>> >> As such, access/retail providers may pay for peering with
>> >> neutral backbone providers for their customers but should
>> >> reject direct peering request from, actively behaving against
>> >> neutrality, CDN providers.
>>
>> > If I am understanding you correctly, are you arguing that anyone with a
>> > network MUST be forced to become a transit provider for anyone else, in
>> the
>> > name of "neutrality"?
>>
>> No, not at all.
>>
>> For example, CDN (N stands for a network) operators may rely on
>> neutral transit providers to connect their CDN to access/retail
>> providers.
>>
>> But, I certainly mean that CDN operators should not request
>> peering directly to access/retail ISPs merely because they have
>> their own transit, because the transit is not at all neutral.
>>
>> Masataka Ohta
>>
>

Re: DNS pulling BGP routes?

[Tom Beecher]

>
> But, I certainly mean that CDN operators should not request
> peering directly to access/retail ISPs merely because they have
> their own transit, because the transit is not at all neutral.
>

I'm still confused.

Let's say I have a CDN network, with a datacenter somewhere, an edge site
somewhere else. I carry my bits from my datacenter, across my internal
network, to my edge site. This is where I intend to hand the bits over to
someone else to carry them to the end user.

Let's say in this site, I have a paid transit connection , and a peering
session directly with the end user's ISP. Where is anything related to
neutrality being 'violated', regardless of which path I choose to send the
bits out?

On Wed, Oct 13, 2021 at 10:36 AM Masataka Ohta <
mo...@necom830.hpcl.titech.ac.jp> wrote:

> Tom Beecher wrote:
>
> >> For network neutrality, backbone providers *MUST* be neutral
> >> for contents they carry.
> >>
> >> However, CDN providers having their own backbone are using
> >> their backbone for contents they prefer, which is *NOT*
> >> neutral at all.
> >>
> >> As such, access/retail providers may pay for peering with
> >> neutral backbone providers for their customers but should
> >> reject direct peering request from, actively behaving against
> >> neutrality, CDN providers.
>
> > If I am understanding you correctly, are you arguing that anyone with a
> > network MUST be forced to become a transit provider for anyone else, in
> the
> > name of "neutrality"?
>
> No, not at all.
>
> For example, CDN (N stands for a network) operators may rely on
> neutral transit providers to connect their CDN to access/retail
> providers.
>
> But, I certainly mean that CDN operators should not request
> peering directly to access/retail ISPs merely because they have
> their own transit, because the transit is not at all neutral.
>
> Masataka Ohta
>

Re: DNS pulling BGP routes?

[Masataka Ohta]

Tom Beecher wrote:


For network neutrality, backbone providers *MUST* be neutral
for contents they carry.

However, CDN providers having their own backbone are using
their backbone for contents they prefer, which is *NOT*
neutral at all.

As such, access/retail providers may pay for peering with
neutral backbone providers for their customers but should
reject direct peering request from, actively behaving against
neutrality, CDN providers.



If I am understanding you correctly, are you arguing that anyone with a
network MUST be forced to become a transit provider for anyone else, in the
name of "neutrality"?


No, not at all.

For example, CDN (N stands for a network) operators may rely on
neutral transit providers to connect their CDN to access/retail
providers.

But, I certainly mean that CDN operators should not request
peering directly to access/retail ISPs merely because they have
their own transit, because the transit is not at all neutral.

Masataka Ohta

Re: DNS pulling BGP routes?

[Tom Beecher]

>
> For network neutrality, backbone providers *MUST* be neutral
> for contents they carry.
>
> However, CDN providers having their own backbone are using
> their backbone for contents they prefer, which is *NOT*
> neutral at all.
>
> As such, access/retail providers may pay for peering with
> neutral backbone providers for their customers but should
> reject direct peering request from, actively behaving against
> neutrality, CDN providers.
>

If I am understanding you correctly, are you arguing that anyone with a
network MUST be forced to become a transit provider for anyone else, in the
name of "neutrality"?

I'll reserve further comment until I make sure I have grasped your point.



On Wed, Oct 13, 2021 at 9:28 AM Masataka Ohta <
mo...@necom830.hpcl.titech.ac.jp> wrote:

> Matthew Petach wrote:
>
> >>> With an anycast setup using the same IP addresses in every
> >>> location, returning SERVFAIL doesn't have the same effect,
> >>> however, because failing over from anycast address 1 to
> >>> anycast address 2 is likely to be routed to the same pop
> >>> location, where the same result will occur.
> >>
> >> That's why that is a bad idea. Alternative name servers with
> >> different IP addresses should be provided at separate locations.
>
> > Sure.  But that doesn't do anything to help prevent the
> > type of outage that hit Facebook, which was the point I
> > was trying to make in my response. Facebook did use > different IP
> addresses, and it didn't matter, because the
>  > underlying health of the network is what was at issue,
>  > not the health of the nameservers.
>
> A possible solution is to force unbundling of CDN providers and
> transit providers by antitrust agencies.
>
> Then, CDN providers can't pursue efficiency only to kill
> fundamental redundancy of DNS.
>
> For network neutrality, backbone providers *MUST* be neutral
> for contents they carry.
>
> However, CDN providers having their own backbone are using
> their backbone for contents they prefer, which is *NOT*
> neutral at all.
>
> As such, access/retail providers may pay for peering with
> neutral backbone providers for their customers but should
> reject direct peering request from, actively behaving against
> neutrality, CDN providers.
>
> > I agree with you--different IP addresses should be
> > used in different geographic locations, even with
> > anycast setups.
> >
> > But people need to also recognize that's not a
> > panacea that solves everything, and that it wouldn't
> > have changed the nature of the outage last week.
>
> We should recognize the fundamental difference between
> independent, thus neutral, backbone providers and
> CDN providers with anti-neutral backbone of their own.
>
> Masataka Ohta
>

Re: S.Korea broadband firm sues Netflix after traffic surge

[Tom Beecher]

I agree with you generally.

It's not impossible, but probably unlikely for an individual to be sued for
contents of cookie data or similar small fragments like that.

I do believe it's orders of more magnitude more likely for the 'average'
residential consumer to attract a suit from the MPAA/RIAA/etc because there
is a torrent stream emanating from their connection, and I have little
faith that any provider would go out of their way to jump in front and say
'no no, that's our tech'.

On Tue, Oct 12, 2021 at 5:15 PM Matthew Petach 
wrote:

>
>
> On Tue, Oct 12, 2021 at 2:01 PM Tom Beecher  wrote:
>
>> I think it would be absolutely *stunning* for content providers
>>> to turn the model on its head; use a bittorrent like model for
>>> caching and serving content out of subscribers homes at
>>> recalcitrant ISPs, so that data doesn't come from outside,
>>> it comes out of the mesh within the eyeball network, with
>>> no clear place for the ISP to stick a $$$ bill to.
>>>
>>
>> I'm familiar with some work and ideas that have gone into such a thing,
>> and I'm personally very much against it for non-technical reasons.
>>
>> Given how far the law lags behind technology, the last thing anyone
>> should be ok with is a 3rd party storing bits on ANYTHING in their house,
>> or transmitting those bits from a network connection that is registered to
>> them.
>>
>
> *chortle*
>
> So, I take it you steadfastly block *all* cookies from being stored
> or transmitted from your browser at home?
>
> Oh, wait.  You meant it's OK to let some third parties
> store and transmit bits from your devices, but only
> the ones you like and support, and as long as they're
> small bits, and you're sure there's nothing harmful or
> illegal in them.
>
> So, that means you check each cookie to make sure
> there's nothing in them that could be illegal?
>
> You sure someone hasn't tucked something like
> the DeCSS algorithm, or the RSA algorithm into
> a cookie in your browser, like this?
>
> https://commons.wikimedia.org/wiki/File:Munitions_T-shirt_(front).jpg
>
> https://www.cafepress.com/+,954530397?utm_medium=cpc_source=pla-google_campaign=7979505756-d-c_content=83814261273-adid-395151690662_term=pla-1396845372217-pid-954530397=Cj0KCQjw5JSLBhCxARIsAHgO2SeM10JbFgeus96hEedn0d0m2Kkz6Z91-frlEIUh-3ZD2w89j8EUmCsaAvnAEALw_wcB
>
> The fact of the matter is, every one of us allows
> third parties to store data on all our devices, all
> the time, and send it back out on the network,
> completely unsupervised by us, even though
> it could contain data which is illegal to cross
> certain arbitrary political boundaries.
>
> I understand where you're coming from, I really
> do.
>
> But I don't think people stop and think about just
> how completely that ship has sailed, from a legal
> standpoint.  You could have been asked by a random
> website to store code which is illegal to export in a
> cookie which is then offered back up to any other
> website in whatever jurisdiction around the globe
> that asks for it, and you'll be completely unaware
> of it, because we've all gotten past the point of "ask
> me about every cookie" being a workable setting on
> any of our devices.
>
> Go ahead.  Turn off all cookie support on all your devices
> for 24 hours.  Don't let any of that third party data in or out
> of your home during that time.
>
> Let me know how well that turns out.
>
> Bonus points if you enforce it on your family/spouse/SO/partner
> at the same time, and they're still talking to you at the end of the
> 24 hours.  ;-P
>
> Matt
>
>
>

Re: DNS pulling BGP routes?

[Masataka Ohta]

Matthew Petach wrote:


With an anycast setup using the same IP addresses in every
location, returning SERVFAIL doesn't have the same effect,
however, because failing over from anycast address 1 to
anycast address 2 is likely to be routed to the same pop
location, where the same result will occur.


That's why that is a bad idea. Alternative name servers with
different IP addresses should be provided at separate locations.



Sure.  But that doesn't do anything to help prevent the
type of outage that hit Facebook, which was the point I
was trying to make in my response. Facebook did use > different IP addresses, 
and it didn't matter, because the

> underlying health of the network is what was at issue,
> not the health of the nameservers.

A possible solution is to force unbundling of CDN providers and
transit providers by antitrust agencies.

Then, CDN providers can't pursue efficiency only to kill
fundamental redundancy of DNS.

For network neutrality, backbone providers *MUST* be neutral
for contents they carry.

However, CDN providers having their own backbone are using
their backbone for contents they prefer, which is *NOT*
neutral at all.

As such, access/retail providers may pay for peering with
neutral backbone providers for their customers but should
reject direct peering request from, actively behaving against
neutrality, CDN providers.


I agree with you--different IP addresses should be
used in different geographic locations, even with
anycast setups.

But people need to also recognize that's not a
panacea that solves everything, and that it wouldn't
have changed the nature of the outage last week.


We should recognize the fundamental difference between
independent, thus neutral, backbone providers and
CDN providers with anti-neutral backbone of their own.

Masataka Ohta