On Sat, 18 May 2024 at 10:38, Bill Woodcock wrote:
> So, yes, I think having an open peering policy should be a requirement for
> operating a root nameserver. I don’t think there’s any defensible rationale
> that would support root nameservers being a private benefit to be used to
> worsen
On Sat, 18 May 2024 at 01:07, William Herrin wrote:
> I don't understand why Cogent is allowed to operate one of the root
> servers. Doesn't ICANN do any kind of technical background check on
> companies when letting the contract?
>
> For those who haven't been around long enough, this isn't
On Fri, 26 Apr 2024 at 19:43, Warren Kumari wrote:
> I've been on the same quest, and I have some additional requests / features.
> Ideally it:
>
> 1: would be small - my particular use-case is for a "traveling rack", and so
> 0U is preferred.
> 2: would be fairly cheap.
> 3: would not be a
On Fri, 26 Apr 2024 at 19:43, Warren Kumari wrote:
>> Curious if anyone has particular hardware they like for OOB / serial
>> management, similar to OpenGear, but preferably with 5G support, maybe even
>> T-Mobile support? It’s becoming increasingly difficult to get static IP 4g
>> machine
On Fri, 26 Apr 2024 at 03:11, David H wrote:
> Curious if anyone has particular hardware they like for OOB / serial
> management, similar to OpenGear, but preferably with 5G support, maybe even
> T-Mobile support? It’s becoming increasingly difficult to get static IP 4g
> machine accounts
On Sun, 21 Apr 2024 at 09:05, Mark Tinka wrote:
> Technically, what you are describing is EoS (Ethernet over SONET, Ethernet
> over SDH), which is not the same as WAN-PHY (although the working groups that
> developed these nearly confused each other in the process, ANSI/ITU for the
> former
On Sat, 20 Apr 2024 at 14:35, Mark Tinka wrote:
> Even when our market seeks OTN from European backhaul providers to extend
> submarine access into Europe and Asia-Pac, it is often for structured
> capacity grooming, and not for OAM benefit.
>
> It would be interesting to learn whether other
On Sat, 20 Apr 2024 at 10:00, Mark Tinka wrote:
> This would only matter on ultra long haul optical spans where the signal
> would need to be regenerated, where - among many other values - FEC would
> need to be decoded, corrected and re-applied.
In most cases, modern optical long haul has a
On Fri, 19 Apr 2024 at 10:55, Mark Tinka wrote:>
FEC is amazing.
> At higher data rates (100G and 400G) for long and ultra long haul optical
> networks, SD-FEC (Soft Decision FEC) carries a higher overhead penalty
> compared to HD-FEC (Hard Decision FEC), but the net OSNR gain more than
>
On Thu, 18 Apr 2024 at 21:49, Aaron Gould wrote:
> Thanks. What "all the ethernet control frame juju" might you be referring
> to? I don't recall Ethernet, in and of itself, just sending stuff back and
> forth. Does anyone know if this FEC stuff I see concurring is actually
> contained in
On Sat, 6 Apr 2024 at 12:00, Bill Woodcock wrote:
> That’s been the normal way of doing it for some 35 years now. iBGP
> advertise, or don’t advertise, the service address, which is attached to the
> loopback, depending whether you’re ready to service traffic.
If we are talking about eBGP,
On Fri, 29 Mar 2024 at 20:10, Steven Bakker wrote:
> To top it off, both the sFlow and IPFIX specs are sufficiently vague about
> the meaning of the "frame size", so vendors can implement whatever they want
> (include/exclude padding, include/exclude FCS). This implies that you
> shouldn't
On Fri, 29 Mar 2024 at 02:15, Nick Hilliard wrote:
> Overall, sflow has one major advantage over netflow/ipfix, namely that
> it's a stateless sampling mechanism. Once you have hardware that can
> Obviously, not all netflow/ipfix implementations implement flow state,
> but most do; some
On Thu, 28 Mar 2024 at 20:36, Peter Phaal wrote:
> The documentation for IOS-XR suggests that enabling extended-router in the
> sFlow configuration should export "Autonomous system path to the
> destination", at least on the 8000 series routers:
>
Hey,
On Thu, 28 Mar 2024 at 17:49, Peter Phaal wrote:
> sFlow was mentioned because I believe Brian's routers support the feature and
> may well export the as-path data directly via sFlow (I am not aware that it
> is a feature widely supported in vendor NetFlow/IPFIX implementations?).
On Wed, 27 Mar 2024 at 21:02, Peter Phaal wrote:
> Brian, you may want to see if your routers support sFlow (vendors have added
> the feature over the last few years).
Why is this a solution, what does it solve for OP? Why is it
meaningful what the wire-format of the records are? I read OP's
On Wed, 6 Mar 2024 at 22:57, michael brooks - ESC
wrote:
> Funny you should mention this now, we were just discussing (more like
> lamenting...) if support is a dying industry. It seems as though vendor
> budgets are shrinking to the point they only have a Sales/Pre-Sales
> department, and
On Fri, 23 Feb 2024 at 19:42, Brandon Martin wrote:
> Before I go to the trouble of making one myself, does anybody happen to
> know of a pre-canned program to generate realistic and scalable amounts
> of broadcast/broad-multicast network background "chatter" seen on
> typical consumer and
On Fri, 26 Jan 2024 at 10:23, Phil Lavin via NANOG wrote:
> 88.99.88.67 to 216.147.3.209:
> Host Loss% Snt Last Avg
> Best Wrst StDev
> 1. 10.88.10.254 0.0% 1760.2 0.1
> 0.1 0.3 0.1
> 7.
On Wed, 17 Jan 2024 at 03:18, wrote:
> Others have pointed to references, I found some others, it's all
> pretty boring but perhaps one should embrace the general point that
> some equipment may not like abrupt temperature changes.
Can you share them? Only one I've found is:
On Tue, 16 Jan 2024 at 12:22, Nathan Ward wrote:
> Here’s some manufacturer specs:
> https://www.dell.com/support/manuals/en-nz/poweredge-r6515/per6515_ts_pub/environmental-specifications?guid=guid-debd273c-0dc8-40d8-abbc-be059a0ce59c=en-us
>
> 3rd section, “Maximum temperature gradient”.
On Tue, 16 Jan 2024 at 11:00, William Herrin wrote:
> You have a computer room humidified to 40% and you inject cold air
> below the dew point. The surfaces in the room will get wet.
I think humidity and condensation is well understood and indeed
documented but by NEBS and vendors as verboten.
On Tue, 16 Jan 2024 at 08:51, wrote:
> A rule of thumb is a few degrees per hour change but YMMV, depends on
> the equipment. Sometimes manufacturer's specs include this.
Is this common sense, or do you have reference to this, like paper
showing at what temperature change at what rate occurs
On Mon, 15 Jan 2024 at 21:08, Michael Thomas wrote:
> An ipv4 free network would be nice, but is hardly needed. There will
> always be a long tail of ipv4 and so what? You deal with it at your
I mean Internet free DFZ, so that everyone is not forced to maintain
two stacks at extra cost,
On Mon, 15 Jan 2024 at 10:59, jordi.palet--- via NANOG wrote:
> No, I’m not saying that. I’m saying "in actual deployments", which doesn’t
> mean that everyone is deploying, we are missing many ISPs, we are missing
> many enterprises.
Because of low entropy of A-B pairs in bps volume, seeing
On Mon, 15 Jan 2024 at 10:05, jordi.palet--- via NANOG wrote:
> In actual customer deployments I see the same levels, even up to 85% of IPv6
> traffic. It basically depends on the usage of the caches and the % of
> residential vs corporate customers.
You think you are contributing to the IPv6
On Mon, 15 Jan 2024 at 06:18, Forrest Christian (List Account) <
li...@packetflux.com> wrote:
If 50٪ of the servers and 50% of the clients can do IPv6, the amount of
> IPv6 traffic will be around 25% since both ends have to do IPv6.
>
This assumes cosmological principle applies to the Internet,
On Thu, 11 Jan 2024 at 12:57, Christopher Hawker wrote:
> Reclassifying this space, would add 10+ years onto the free pool for each
> RIR. Looking at the APNIC free pool, I would estimate there is about 1/6th of
> a /8 pool available for delegation, another 1/6th reserved. Reclassification
>
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.
On Mon, 27 Nov 2023 at 21:45, Josh Luthman
wrote:
Can you have an ethernet switch with dying gasp?
> Our ONTs (Calix, PON) have it but I don't see how you'd do it with
> ethernet.
>
At least via efm-oam you can have a dying gasp.
You could probably add it to autonegotiation, by sending some
On Thu, 2 Nov 2023 at 10:32, Mark Andrews wrote:
> You missed the point I was trying to make. While I think that that source is
> trying to enumerate some part of the namespace. NS queries by themselves
> don’t indicate an attack. Others would probably see the series of NS queries
> as a
On Wed, 18 Oct 2023 at 17:39, Tom Beecher wrote:
> Auto-bandwidth won't help here if the bandwidth reduction is 'silent' as
> stated in the first message. A 1G interface , as far as RSVP is concerned, is
> a 1G interface, even if radio interference across it means it's effectively a
> 500M
On Mon, 16 Oct 2023 at 22:49, wrote:
> JTAC says we must disable a physical port to allocate BW for tunnel-services.
> Also leaving tunnel-services bandwidth unspecified is not possible on the
> 204. I haven't independently tested / validated in lab yet, but this is what
> they have told
On Tue, 17 Oct 2023 at 00:28, Delong.com wrote:
> The MX-204 appears to be an entirely fixed configuration chassis and looks
> from the literature like it is based on pre-trio chipset technology.
> Interesting that there are 100Gbe interfaces implemented with this seemingly
> older
Unfortunately not yet, as far as I know. Long time ago I gave this to
my account team
Title: Direct routes must support tag and or community
Platform: Trio, priority MX80, MPC2
JunOS: 12.4Rx
Command: 'set interfaxe ge-4/2.0 family inet address 10.42.42.1/24
tag|community X'
JTAC:
On Thu, 5 Oct 2023 at 20:45, Niels Bakker wrote:
> The recommendation is to make Router-IDs globally unique. They're used
> in collision detection. What if you and a peer pick the same non
> globally unique address? Any session will never come up.
https://datatracker.ietf.org/doc/html/rfc6286
On Mon, 2 Oct 2023 at 20:21, Jeff Behrns via NANOG wrote:
> Encountered an issue with an MX204 using all 4x100G ports and a logical
> tunnel to hairpin a VRF. The tunnel started dropping packets around 8Gbps.
> I bumped up tunnel-services BW from 10G to 100G which made the problem
> worse; the
On Sun, 1 Oct 2023 at 21:19, Matthew Petach wrote:
> Unfortunately, many coders today have not read Godel, Escher, Bach: An
> Eternal Golden Braid,
> and like the unfortunate Crab, consider their FIB compression algorithms to
> be unbreakable[0].
>
> In short: if you count on FIB compression
On Sun, 1 Oct 2023 at 06:07, Owen DeLong via NANOG wrote:
> Not sure why you think FIB compression is a risk or will be a mess. It’s a
> pretty straightforward task.
Also people falsely assume that the parts they don't know about, are
risk free and simple.
While in reality there are tons of
On Sat, 30 Sept 2023 at 09:42, Mark Tinka wrote:
> > But when everybody upgrades, memory and processor unit prices
> > decrease.. Vendors gain from demand.
> >
> I am yet to see that trend...
Indeed. If you look like 10k/10q for Juniper their business is fairly
stable in revenue and ports sold.
On Fri, 29 Sept 2023 at 23:43, William Herrin wrote:
> My understanding of Juniper's approach to the problem is that instead
> of employing TCAMs for next-hop lookup, they use general purpose CPUs
> operating on a radix tree, exactly as you would for an all-software
They use proprietary NPUs,
On Fri, 29 Sept 2023 at 08:24, William Herrin wrote:
> Maybe. That's where my comment about CPU cache starvation comes into
> play. I haven't delved into the Juniper line cards recently so I could
> easily be wrong, but if the number of routes being actively used
> pushes past the CPU data
On Wed, 20 Sept 2023 at 19:06, Chris Boyd wrote:
> We run Teams Telephony in $DAYJOB, and it does use SILK.
>
> https://learn.microsoft.com/en-us/microsoftteams/platform/bots/calls-and-meetings/real-time-media-concepts
Looks like codecs still are rapidly evolving in walled gardens. I just
On Wed, 20 Sept 2023 at 03:15, Dave Taht wrote:
> I go back many, many years as to baseline numbers for managing voip networks,
> including things like CISCO LLQ, diffserv, fqm prioritizing vlans, and running
> voip networks entirely separately... I worked on codecs, such as oslec, and
> early
On Sat, 9 Sept 2023 at 21:36, Benny Lyne Amorsen
wrote:
> The Linux TCP stack does not immediately start backing off when it
> encounters packet reordering. In the server world, packet-based
> round-robin is a fairly common interface bonding strategy, with the
> accompanying reordering, and
On Fri, 8 Sept 2023 at 09:17, Mark Tinka wrote:
> > Unfortunately that is not strict round-robin load balancing.
>
> Oh? What is it then, if it's not spraying successive packets across
> member links?
I believe the suggestion is that round-robin out-performs random
spray. Random spray is what
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.
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.
On Wed, 6 Sept 2023 at 19:28, Mark Tinka wrote:
> Yes, this has been my understanding of, specifically, Juniper's
> forwarding complex.
Correct, packet is sprayed to some PPE, and PPEs do not run in
deterministic time, after PPEs there is reorder block that restores
flow, if it has to.
EZchip
On Wed, 6 Sept 2023 at 17:10, Benny Lyne Amorsen
wrote:
> TCP looks quite different in 2023 than it did in 1998. It should handle
> packet reordering quite gracefully; in the best case the NIC will
I think the opposite is true, TCP was designed to be order agnostic.
But everyone uses cubic, and
On Wed, 6 Sept 2023 at 10:27, Mark Tinka wrote:
> I recognize what happens in the real world, not in the lab or text books.
Fun fact about the real world, devices do not internally guarantee
order. That is, even if you have identical latency links, 0
congestion, order is not guaranteed between
On Fri, 1 Sept 2023 at 22:56, Mark Tinka wrote:
> PTX1000/10001 (Express) offers no real configurable options for load
> balancing the same way MX (Trio) does. This is what took us by surprise.
What in particular are you missing?
As I explained, PTX/MX both allow for example speculating on
On Fri, 1 Sept 2023 at 18:37, Lukas Tribus wrote:
> On the hand a workaround at the edge at least for EoMPLS would be to
> enable control-word.
Juniper LSR can actually do heuristics on pseudowires with CW.
--
++ytti
On Fri, 1 Sept 2023 at 16:46, Mark Tinka wrote:
> Yes, this was our conclusion as well after moving our core to PTX1000/10001.
Personally I would recommend turning off LSR payload heuristics,
because there is no accurate way for LSR to tell what the label is
carrying, and wrong guess while rare
On Fri, 1 Sept 2023 at 14:54, Mark Tinka wrote:
> When we switched our P devices to PTX1000 and PTX10001, we've had
> surprisingly good performance of all manner of traffic across native
> IP/MPLS and 802.1AX links, even without explicitly configuring FAT for
> EoMPLS traffic.
PTX and MX as LSR
On Thu, 31 Aug 2023 at 23:56, Eric Kuhnke wrote:
> The best working theory that several people I know in the neteng community
> have come up with is because Cogent does not want to adversely impact all
> other customers on their router in some sites, where the site's upstreams and
> links to
On Tue, 22 Aug 2023 at 03:30, Lyndon Nerenberg (VE7TFX/VE6BBM)
wrote:
> Because I've been writing yacc grammars for decades. I just wanted to
> see if someone had already done it, as that would save me some time.
> But if there's nothing out there I'll just roll one myself.
I sympathise with
Does anyone have a traceroute path example where transit responds with
RFC5837 EO?
https://github.com/8enet/traceroute/blob/master/traceroute/extension.c#L101
Output should be '2/x: '
At least JNPR seems to support this:
This seems worse :)
'we are collecting data about you, but didn't bother thinking if it is needed'
On Fri, 16 Jun 2023 at 22:55, Livingood, Jason via NANOG
wrote:
>
> In the meantime please just select some unrelated industry on the form. We
> don’t care – it seems to be boilerplate.
>
>
>
>
I can't tell what large is. But I've worked for enterprise ISP and
consumer ISPs, and none of the shops I worked for had capability to
monetise information they had. And the information they had was
increasingly low resolution. Infraprovider are notoriously bad even
monetising their infra.
I'm
On Fri, 21 Apr 2023 at 20:44, Jason Healy via NANOG wrote:
> This is not intended as snark: what do people recommend for IPv6? I try to
> maintain forward/reverse for all my server/infrastructure equipment. But
> clients? They're making up temporary addresses all day long. So far, I've
>
On Wed, 22 Mar 2023 at 16:04, Alexander Huynh via NANOG wrote:
> I'll take this feedback to our developers.
Many thanks.
> I took a look at the above tickets, and it seems that one of the egress
> ranges from that datacenter cannot connect to the authoritative
> nameservers of
perati...@lists.dns-oarc.net for someone at CloudFlare.
>
> For what it's worth, it works for me. I'm in Troy, OH.
>
> C:\Users\jluthman>dig www.moi.gov.cy @1.1.1.1 +short
> 212.31.118.26
>
>
> On Wed, Mar 22, 2023 at 9:43 AM Saku Ytti wrote:
>>
>>
>>
On Wed, 22 Mar 2023 at 15:26, Matt Harris wrote:
> When something is provided at no cost, I don't see how it can be unethical
> unless they are explicitly lying about the ways in which they use the data
> they gather.
> Ultimately, you're asking them to provide a costly service (support for
>
i.gov.cy. 3600 IN NS ns01.gov.cy.
> moi.gov.cy. 3600 IN NS ns02.gov.cy.
>
> ;; ADDITIONAL SECTION:
> ns02.gov.cy. 86400 IN A 212.31.118.20
> ns01.gov.cy. 86400 IN A 212.31.118.19
>
> ;; Query time: 374 msec
> ;; SERVER: 212.31.118.19#53(212.31.118.19) (UDP)
> ;; WHEN:
Am I correct to understand that 1.1.1.1 only does support via community forum?
They had just enough interest in the service to collect user data to
monetise, but 0 interest in trying to figure out how to detect and
solve problems?
Why not build a web form where they ask you to explain what is
On Mon, 27 Feb 2023 at 10:16, Rolf Winter wrote:
> "https://downforeveryoneorjustme.com/;. But, somebody might use your
> server for this. How do people feel about this? Restrict the reverse
> traceroute operation to be done back to the source or allow it more
> freely to go anywhere?
What are
╰─ dig NS intuit.com|grep ^intuit|ruby -nae 'puts $F[-1]'|while read dns;do
echo $dns:;dig smartlinks.intuit.com @$dns|grep CNAME
done
a7-66.akam.net.:
smartlinks.intuit.com. 30 IN CNAME cegnotificationsvc.intuit.com.
a11-64.akam.net.:
smartlinks.intuit.com. 30 IN CNAME
On Sun, 5 Feb 2023 at 07:50, Chris Adams wrote:
> Electric heat pumps are great for power efficiency until the temperature
> drops and they switch over to pure electric heat.
Here is graph from popular air heat pump Mitsubishi MSZ/MUZ 25
On Fri, 3 Feb 2023 at 16:15, Israel G. Lugo wrote:
> Could anyone with last mile experience help with some ballpark figures?
> I.e. 15 min vs 8h or 8 days.
This would be highly market specific. In many cases, probably most
cases, there is no regulatory requirement for availability for
internet
On Sat, 28 Jan 2023 at 08:48, Mark Tinka wrote:
> Apparently, the shortage of chips for the MX204 and MPC7E is now resolved,
> and there is no longer any need to force customers to move to the MX304.
There is still just Micron for HMC, and as far as I can find, they've
not revoked their EOL.
On Thu, 22 Dec 2022 at 08:41, William Herrin wrote:
> Suppose you have a loose network cable between your Linux server and a
> switch. Layer 1. That RJ45 just isn't quite solid. It's mostly working
> but not quite right. What does it look like at layer 2? One thing it
> can look like is a
There certainly aren't any temporal buffers in SP gear limiting the
buffer to 100ms, nor are there any mechanisms to temporally decrease
TTL or hop-limit. Some devices may expose temporal configuration to
UX, but that is just a multiplier for max_buffer_bytes, and what is
programmed is a fixed
On Fri, 9 Dec 2022 at 20:19, t...@pelican.org wrote:
Hey Tim,
> Or at least, you've moved the problem from "generate config" to "have
> complete and correct data". Which statement should probably come with some
> kind of trigger-warning...
I think it's a lot easier than you think. I
On Fri, 9 Dec 2022 at 17:58, Joshua Miller wrote:
> In terms of structured vs unstructured data, sure, assembling text is not a
> huge lift. Though, when you're talking about layering on complex use cases,
> then it gets more complicated. Especially if you want to compute the inverse
>
On Fri, 9 Dec 2022 at 17:30, Tom Beecher wrote:
> Pushing thousands of lines via CLI/expect automation is def not a great idea,
> no. Putting everything into a file, copying that to the device, and loading
> from there is generally best regardless. The slowness you refer to is almost
>
On Fri, 9 Dec 2022 at 17:07, Joshua Miller wrote:
> I don't know that Netconf or gRPC are any faster than loading cli. Those
> protocols facilitate automation so that the time it takes to load any one
> device is not a significant factor, especially when you can roll out changes
> to devices
Can Andrian and Joshua explain what they specifically mean, and how
they expect it to perform over what Steffann is already doing (e.g.
load https://nms/cfg/router.txt)? How much faster will it be, and why?
Can Steffan explain how large a file they are copying, over what
protocol, how long does
I don't think this is normal, I think this is a fault and needs to be
addressed. There should be significant reachability problems, because
rerouting isn't neither immediate, nor lock-step with SW+HW nor
synchronous between nodes.
What exactly needs to be done, I can't tell without looking at the
Hey,
On Mon, 7 Nov 2022 at 21:58, Graham Johnston wrote:
> I've been involved in service provider networks, small retail ISPs, for 20+
> years now. Largely though, we've never needed complex QoS, as at
> $OLD_DAY_JOB, we had been consistently positioned to avoid regular link
> congestion
On Fri, 9 Sept 2022 at 09:31, Crist Clark wrote:
> As I said in the original email, I realize router IDs just need to be
> unique in
> an AS. We could have done random ones with IPv4, but using a well chosen
In some far future this will be true. We meet eBGP speakers across the
world, and not
On Thu, 8 Sept 2022 at 10:22, Bjørn Mork wrote:
> I'm not used to punching anything, so I probably have too simple a view
> of the world.
>
> But I still don't understand how this changes the ID allocation scheme,
> which is how I understood the question. I assume the punched value was
> based
On Thu, 8 Sept 2022 at 10:01, Bjørn Mork wrote:
> Why would you do it differently than for dual-stack routers, except that
> you skip the step where you configure the ID as a loopback address?
Because you may not have an option, if you're IPv6 only, vendors (e.g.
junos) may expect you to punch
Hey,
> Well, now there is no IPv4. But BGP, OSPFv3, and other routing protocols
> still use 32-bit router IDs for IPv6. On the one hand, there are plenty of
> 32-bit numbers to use. Generally speaking, router IDs just need to be unique
> inside of an AS to do their job, but (a) for humans or
On Thu, 8 Sept 2022 at 01:06, Jawaid Bazyar wrote:
> $1 deals usually come with an operation in the red, or assumption of
> significant debts.
To me this looks like a continuation of the game of attrition for
infrastructure players. No one seems to know how to capitalise
infrastructure, and
On Wed, 10 Aug 2022 at 12:48, Pascal Thubert (pthubert)
wrote:
Hey,
> I do not share that view:
I'm not sure how you read my view. I was not attempting to communicate
anything negative of IPv6. What I attempted to communicate
- near future looks to improve IOT security posture significantly,
On Wed, 10 Aug 2022 at 06:48, wrote:
> How do you propose to fairly distribute market data feeds to the market if
> not multicast?
I expected your aggressive support for small packets was for fintech.
An anecdote:
one of the largest exchanges in the world used MX for multicast
replication,
On Wed, 10 Aug 2022 at 07:54, Pascal Thubert (pthubert) via NANOG
wrote:
> On a more positive note, the IPv6 IoT can be seen as an experiment on how we
> can scale the internet another order of magnitude or 2 without taking the
> power or the spectrum consumption to the parallel levels.
I
On Mon, 8 Aug 2022 at 14:37, Masataka Ohta
wrote:
> With such an imaginary assumption, according to the end to end
> principle, the customers (the ends) should use paced TCP instead
I fully agree, unfortunately I do not control the whole problem
domain, and the solutions available with partial
On Mon, 8 Aug 2022 at 14:02, Masataka Ohta
wrote:
> which is, unlike Yttinet, the reality.
Yttinet has pesky customers who care about single TCP performance over
long fat links, and observe poor performance with shallow buffers at
the provider end. Yttinet is cost sensitive and does not want to
On Mon, 8 Aug 2022 at 13:03, Masataka Ohta
wrote:
> If RTT is large, your 100G runs over several 100/400G
> backbone links with many other traffic, which makes the
> burst much slower than 10G.
In Ohtanet, I presume.
--
++ytti
On Sun, 7 Aug 2022 at 14:16, Masataka Ohta
wrote:
> When many TCPs are running, burst is averaged and traffic
> is poisson.
If you grow a window, and the sender sends the delta at 100G, and
receiver is 10G, eventually you'll hit that 10G port at 100G rate.
It's largely an edge problem, not a
On Sun, 7 Aug 2022 at 17:58, wrote:
> There are MANY real world use cases which require high throughput at 64 byte
> packet size. Denying those use cases because they don’t fit your world view
> is short sighted. The word of networking is not all I-Mix.
Yes but it's not an addressable market.
On Sun, 7 Aug 2022 at 12:16, Masataka Ohta
wrote:
> I'm afraid you imply too much buffer bloat only to cause
> unnecessary and unpleasant delay.
>
> With 99% load M/M/1, 500 packets (750kB for 1500B MTU) of
> buffer is enough to make packet drop probability less than
> 1%. With 98% load, the
On Sat, 6 Aug 2022 at 17:08, wrote:
> For a while, GSR and CRS type systems had linecards where each card had a
> bunch of chips that together built the forwarding pipeline. You had chips
> for the L1/L2 interfaces, chips for the packet lookups, chips for the
> QoS/queueing math, and chips
On Sat, 6 Aug 2022 at 23:08, Eric Kuhnke wrote:
> I have a morbid curiosity about what the CRM database looks like inside
> Cogent, for the stale/cold leads that get passed on to a new junior sales rep
> every six months.
>
> The amount of peoples' names/email addresses/phone numbers in there
On Fri, 5 Aug 2022 at 20:31, wrote:
Hey LJ,
> Disclaimer: I work for Cisco on a bunch of silicon. I'm not intimately
> familiar with any of these devices, but I'm familiar with the high level
> tradeoffs. There are also exceptions to almost EVERYTHING I'm about to say,
> especially once
Thank you for this.
I wish there would have been a deeper dive to the lookup side. My open questions
a) Trio model of packet stays in single PPE until done vs. FP model of
line-of-PPE (identical cores). I don't understand the advantages of
the FP model, the Trio model advantages are clear to me.
On Tue, 26 Jul 2022 at 23:15, Jeff Tantsura wrote:
> In general, if we look at the whole spectrum, on one side there’re massively
> parallelized “many core” RTC ASICs, such as Trio, Lightspeed, and similar (as
> the last gasp of Redback/Ericsson venture - we have built 1400 HW threads
> ASIC
On Tue, 26 Jul 2022 at 21:28, wrote:
> >No you are right, FP has much much more PPEs than Trio.
>
> Can you give any examples?
Nokia FP is like >1k, Juniper Trio is closer to 100 (earlier Trio LUs
had much less). I could give exact numbers for EA and YT if needed,
they are visible in the CLI
1 - 100 of 857 matches
Mail list logo
