maximum ipv4 bgp prefix length of /24 ?
hello, I believe, ISPs should also allow ipv4 prefixes with length between /25-/27 instead of limiting maximum length to /24.. I also believe that RIRs and LIRs should allocate /27s which has 32 IPv4 address. considering IPv4 world is now mostly NAT'ed, 32 IPv4s are sufficient for most of the small and medium sized organizations and also home office workers like youtubers, and professional gamers and webmasters! It is because BGP research and experiment networks can not get /24 due to high IPv4 prices, but they have to get an IPv4 prefix to learn BGP in IPv4 world. What do you think about this? What could be done here? Is it unacceptable; considering most big networks that do full-table-routing also use multi-core routers with lots of RAM? those would probably handle /27s and while small networks mostly use default routing, it should be reasonable to allow /25-/27? Thanks for reading, regards..
Re: maximum ipv4 bgp prefix length of /24 ?
IMO, No. ipv4 is not dead yet. we need to raise it, a bit. EINAT solutions are OK The future will come very quickly, right now. We just need to invest in the internet. 29.09.2023 07:11 tarihinde Owen DeLong yazdı: Wouldn’t /48s be a better solution to this need? Owen On Sep 28, 2023, at 14:25, VOLKAN SALİH wrote: hello, I believe, ISPs should also allow ipv4 prefixes with length between /25-/27 instead of limiting maximum length to /24.. I also believe that RIRs and LIRs should allocate /27s which has 32 IPv4 address. considering IPv4 world is now mostly NAT'ed, 32 IPv4s are sufficient for most of the small and medium sized organizations and also home office workers like youtubers, and professional gamers and webmasters! It is because BGP research and experiment networks can not get /24 due to high IPv4 prices, but they have to get an IPv4 prefix to learn BGP in IPv4 world. What do you think about this? What could be done here? Is it unacceptable; considering most big networks that do full-table-routing also use multi-core routers with lots of RAM? those would probably handle /27s and while small networks mostly use default routing, it should be reasonable to allow /25-/27? Thanks for reading, regards..
Re: maximum ipv4 bgp prefix length of /24 ?
Thanks for sharing ideas. I respect them all. 29.09.2023 07:31 tarihinde William Herrin yazdı: I think you'll convince the IETF to release the Class-E space before you convince the ISPs to broadly honor sub-/24 prefixes.
Re: maximum ipv4 bgp prefix length of /24 ?
how would you route 800 Gigabit-ethernet that will soon be released as IEEE standart? we were paying 1 usd per megabit several years ago. now it is as low as 4 usd cent. As i said before, the future is coming just now. There must be ways to increase CPU caches and memories of routers. It is also about wholesale. When you buy cheaper routers, powerful routers stay expensive. But when everybody upgrades, memory and processor unit prices decrease.. Vendors gain from demand. 29.09.2023 07:31 tarihinde William Herrin yazdı: Others use an expensive kind of memory called a TCAM that's very fast but both expensive and power hungry, so generally not sized for huge numbers of tiny routes.
Re: maximum ipv4 bgp prefix length of /24 ?
Also keep in mind; single-homed networks never need full-table.. multi-homed networks could also do default routing just packet-mark incoming interface and then route packets out via same interface.. I do not see gain in running BGP full-table, _*excluding*_ networks using Intelligent routing optimizers that run jitter and ping tests.. but these are just my ideas.., i respect all ideas.. we are here to discuss.. There are people running full-table of v4 and v6 _*just for fun*_... I guess it makes them happy when they look thousands of routes available on single interface! I am pretty sure Tier-1 and Tier-2 networks have enough money for upgrades. But i may be wrong. What do you think? Thanks and regards 29.09.2023 07:43 tarihinde VOLKAN SALİH yazdı: how would you route 800 Gigabit-ethernet that will soon be released as IEEE standart? we were paying 1 usd per megabit several years ago. now it is as low as 4 usd cent. As i said before, the future is coming just now. There must be ways to increase CPU caches and memories of routers. It is also about wholesale. When you buy cheaper routers, powerful routers stay expensive. But when everybody upgrades, memory and processor unit prices decrease.. Vendors gain from demand. 29.09.2023 07:31 tarihinde William Herrin yazdı: Others use an expensive kind of memory called a TCAM that's very fast but both expensive and power hungry, so generally not sized for huge numbers of tiny routes.
Re: maximum ipv4 bgp prefix length of /24 ?
CGNAT is not worse any more, IMHO. with Endpoint-independent-NAT you can accept incoming connections, as soon as you open the port automatically by sending packet to any host. Then any host can start connection to your host? thats perfect for gamers, streamers, webmasters.. etc.. Allows P2P connections.. for server setups, how many common ports you need to forward? five or ten, maybe. not that bad. if it is scripted, then it is automated. if its automated then it is not headache for network administrator.. There are just about 50 major NSP networks on the Earth, that needs to use BGP full-table. I presume there would be another 50 big ASNs that belong to CDNs. And I am pretty sure those top 100 networks can invest in gear to support /25-/27. I would suggest Tier3 eyeballs to mark connection depending on incoming interface (transit provider). Then route outgoing traffic of connections via same interface (TP). Thats all they need to do. if they do not optimize BGP based on packetloss rate and latency (performance). Please Correct me if i am wrong. Thanks and regards 29.09.2023 07:48 tarihinde Owen DeLong yazdı: I presume you mean CGNAT? Otherwise, not sure what EINAT is and couldn’t find a reference with a quick google search. Again agree to disagree. NAT is bad and more NAT is just worse.
Re: maximum ipv4 bgp prefix length of /24 ?
Can we get single-homed and dual-homed ASN counts worldwide by somebody here? Checking, https://bgp.he.net/country/US , more than half of networks are either single-homed or dual-homed. single-homed networks do not need full-table, for sure. Dual homed networks need to buy partial transit from the notorious tier-1.5 network that has "NO" (close the doors) peering policy, that you know their name.. Then route other traffic via cheapest second Transit Provider.. /BTW, Thanks Mr. M.Leber for shitting in the world-wide IPv6 internet (causing segmentation in the IPv6 world), I guess he thinks FREE means FEELESS while it means mostly freedom../ /It seems like Mr. M.Leber believes dictatorship instead of freedom. Wake up, Nobody have to do peer with you for free (settlement-free), but you can negotiate the price/mbps./ 29.09.2023 08:01 tarihinde VOLKAN SALİH yazdı: CGNAT is not worse any more, IMHO. with Endpoint-independent-NAT you can accept incoming connections, as soon as you open the port automatically by sending packet to any host. Then any host can start connection to your host? thats perfect for gamers, streamers, webmasters.. etc.. Allows P2P connections.. for server setups, how many common ports you need to forward? five or ten, maybe. not that bad. if it is scripted, then it is automated. if its automated then it is not headache for network administrator.. There are just about 50 major NSP networks on the Earth, that needs to use BGP full-table. I presume there would be another 50 big ASNs that belong to CDNs. And I am pretty sure those top 100 networks can invest in gear to support /25-/27. I would suggest Tier3 eyeballs to mark connection depending on incoming interface (transit provider). Then route outgoing traffic of connections via same interface (TP). Thats all they need to do. if they do not optimize BGP based on packetloss rate and latency (performance). Please Correct me if i am wrong. Thanks and regards 29.09.2023 07:48 tarihinde Owen DeLong yazdı: I presume you mean CGNAT? Otherwise, not sure what EINAT is and couldn’t find a reference with a quick google search. Again agree to disagree. NAT is bad and more NAT is just worse.
Re: maximum ipv4 bgp prefix length of /24 ?
Many people from big companies/networks are either member of NANOG or following/reading NANOG from archives. I was also going to ask if anyone / any company can sponsor (feeless) IPv4 /24 prefix for my educational research network? (as209395) We do not do or allow SPAM/spoofing and other illegal stuff, we have RPKI records and check RPKI of BGP peers. We also consider to have BGP session with HE.net and CogentCo in the future, so we can re-announce their single-homed prefixes to each other, as charity. For the good of everyone on the internet.. Mr. M.Leber from He.net also stopped feeless BGP tunnel service, as he has not seen financial benefit, while still talking about community-give-back?! And he still seeks feeless peering from CogentCo, you get what you give.whatever goes around comes around Thanks for reading, best regards and wishes 29.09.2023 09:57 tarihinde Vasilenko Eduard yazdı: Well, it depends. The question below was evidently related to business. IPv6 does not have yet a normal way of multihoming for PA prefixes. If IETF (and some OTTs) would win blocking NAT66, Then /48 propoisiton is the proposition for PA (to support multihoming). Unfortunately, it is at least a 10M global routing table as it has been shown by Brian Carpenter. Reminder, The IPv6 scale on all routers is 2x smaller (if people would use DHCP and longer than/64 then the scale would drop 2x additionally). Hence, /48 proposition may become 20x worse for scale than proposed initially in this thread. Eduard *From:*NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org] *On Behalf Of *Owen DeLong via NANOG *Sent:* Friday, September 29, 2023 7:11 AM *To:* VOLKAN SALİH *Cc:* nanog@nanog.org *Subject:* Re: maximum ipv4 bgp prefix length of /24 ? Wouldn’t /48s be a better solution to this need? Owen On Sep 28, 2023, at 14:25, VOLKAN SALİH wrote: hello, I believe, ISPs should also allow ipv4 prefixes with length between /25-/27 instead of limiting maximum length to /24.. I also believe that RIRs and LIRs should allocate /27s which has 32 IPv4 address. considering IPv4 world is now mostly NAT'ed, 32 IPv4s are sufficient for most of the small and medium sized organizations and also home office workers like youtubers, and professional gamers and webmasters! It is because BGP research and experiment networks can not get /24 due to high IPv4 prices, but they have to get an IPv4 prefix to learn BGP in IPv4 world. What do you think about this? What could be done here? Is it unacceptable; considering most big networks that do full-table-routing also use multi-core routers with lots of RAM? those would probably handle /27s and while small networks mostly use default routing, it should be reasonable to allow /25-/27? Thanks for reading, regards..
Re: maximum ipv4 bgp prefix length of /24 ?
I dont even have money for food/living. i am working poor. poverty line is 40 thousands turkish liras here.. but for a green card, I can carve mr leber or mr schaeffer settlement-free! _*JK!*_ lucifer told me to ask for green card, too.. ;P you guys become rich this way.. by playing penny pincher. I asked global firms like Huawei, not some local company called ADAMS! RIB, FIB doesnt matter, internet is our future, so lets invest in it. 29.09.2023 20:13 tarihinde Jason Baugher yazdı: Let me see if I can summarize, tell me where I’m wrong… You: Give me this for free, give me that for free, sponsor me, why isn’t HE giving me something for free, everyone else should spend money to upgrade infrastructure to handle my request for /27, but I shouldn’t have to pay for anything… Jason *From:*NANOG *On Behalf Of *VOLKAN SALIH *Sent:* Friday, September 29, 2023 2:45 AM *To:* Vasilenko Eduard ; Owen DeLong *Cc:* nanog@nanog.org *Subject:* Re: maximum ipv4 bgp prefix length of /24 ? CAUTION: This email is from *OUTSIDE* our organization. Please do not open/download any attachment or click any link unless you know it's safe. Many people from big companies/networks are either member of NANOG or following/reading NANOG from archives. I was also going to ask if anyone / any company can sponsor (feeless) IPv4 /24 prefix for my educational research network? (as209395) We do not do or allow SPAM/spoofing and other illegal stuff, we have RPKI records and check RPKI of BGP peers. We also consider to have BGP session with HE.net and CogentCo in the future, so we can re-announce their single-homed prefixes to each other, as charity. For the good of everyone on the internet.. Mr. M.Leber from He.net also stopped feeless BGP tunnel service, as he has not seen financial benefit, while still talking about community-give-back?! And he still seeks feeless peering from CogentCo, you get what you give.whatever goes around comes around Thanks for reading, best regards and wishes 29.09.2023 09:57 tarihinde Vasilenko Eduard yazdı: Well, it depends. The question below was evidently related to business. IPv6 does not have yet a normal way of multihoming for PA prefixes. If IETF (and some OTTs) would win blocking NAT66, Then /48 propoisiton is the proposition for PA (to support multihoming). Unfortunately, it is at least a 10M global routing table as it has been shown by Brian Carpenter. Reminder, The IPv6 scale on all routers is 2x smaller (if people would use DHCP and longer than/64 then the scale would drop 2x additionally). Hence, /48 proposition may become 20x worse for scale than proposed initially in this thread. Eduard *From:*NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org <mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org>] *On Behalf Of *Owen DeLong via NANOG *Sent:* Friday, September 29, 2023 7:11 AM *To:* VOLKAN SALİH <mailto:volkan.salih...@gmail.com> *Cc:* nanog@nanog.org *Subject:* Re: maximum ipv4 bgp prefix length of /24 ? Wouldn’t /48s be a better solution to this need? Owen On Sep 28, 2023, at 14:25, VOLKAN SALİH wrote: hello, I believe, ISPs should also allow ipv4 prefixes with length between /25-/27 instead of limiting maximum length to /24.. I also believe that RIRs and LIRs should allocate /27s which has 32 IPv4 address. considering IPv4 world is now mostly NAT'ed, 32 IPv4s are sufficient for most of the small and medium sized organizations and also home office workers like youtubers, and professional gamers and webmasters! It is because BGP research and experiment networks can not get /24 due to high IPv4 prices, but they have to get an IPv4 prefix to learn BGP in IPv4 world. What do you think about this? What could be done here? Is it unacceptable; considering most big networks that do full-table-routing also use multi-core routers with lots of RAM? those would probably handle /27s and while small networks mostly use default routing, it should be reasonable to allow /25-/27? Thanks for reading, regards.. *Jason Baugher, Network Operations Manager* 405 Emminga Road | PO Box 217 | Golden, IL 62339-0217 P (217) 696-4411 | F (217) 696-4811 | *www.adams.net* <http://www.adams.net/> Adams-Logo <http://adams.net/> The information contained in this email message is PRIVILEGED AND CONFIDENTIAL, and is intended for the use of the addressee and no one else. If you are not the intended recipient, please do not read, distribute, reproduce or use this email message (or the attachments) and notify the sender of the mistaken transmission. Thank you.
Re: maximum ipv4 bgp prefix length of /24 ?
thanks for your response. Honestly thanks for everyones reponses. comunism is the future. IMO. tier-1 network count is decreasing. competition is always good. while monopoly, duopoly, triopoly is not.. I dream an earth with 1000 tier-1 networks.. capitalism give people more money than they can spend in their lifetime with their families, but it doesnt give people happiness and health.. for example, if i were level3 or telia CEO or should I have been major stakeholder? I would like to see 50 or 1000 more tier-1 networks competing with us. Money is not everything. After some time capitalist bourgeois realize that they could not "earn" health or happiness and start spending their pennies to charities, because if we wouldnt believe heaven and hell and purgatory, what else we could believe? Should we believe that after death nothing left from the earth, we worked for nothing, we laughed for nothing, we cried for nothing, and we married for nothing? NOPE. Everyone is equal, in the god's/lord's/creator's vision. You need to work on comunism instead of capitalism.. I do not care what CFO/CTO/CEO/CXO thinks! they are more miserable than me..! I am healthy and happy. They are not. They can not be. I just expressed my opinions, finalized them with a bad joke. ;D You can continue your feasibility reports, net profit margin , return of investment calculations, but the god doesnt care IMO, and you will not care after you are 70-80 years.old. Best regards and wishes for you all I guess i made myself clear. Development is the only way. in all aspects. 29.09.2023 20:31 tarihinde Matthew Petach yazdı: On Fri, Sep 29, 2023 at 9:42 AM VOLKAN SALİH wrote: [...] I presume there would be another 50 big ASNs that belong to CDNs. And I am pretty sure those top 100 networks can invest in gear to support /25-/27. Volkan, So far, you haven't presented any good financial reason those top 100 networks should spend millions of dollars to upgrade their networks just so your /27 can be multihomed. Sure, they *can* invest in gear to support /25-/27; but they won't, because there's no financial benefit for them to do so. I know from *your* side of the table, it would make your life better if everyone would accept /27 prefixes--multihoming for the masses, yay! Try standing in their shoes for a minute, though. You need to spend tens of millions of dollars on a multi-year refresh cycle to upgrade hundreds of routers in your global backbone, tying up network engineering resources on upgrades that at the end, will bring you exactly $0 in additional revenue. Imagine you're the COO or CTO of a Fortune 500 network, and you're meeting with your CFO to pitch this idea. You know your CFO is going to ask one question right off the bat "what's the timeframe for us to recoup the cost of this upgrade?" (hint, he's looking for a number less than 40 months). If your answer is "well, we're never going to recoup the cost. It won't bring us any additional customers, it won't bring us any additional revenue, and it won't make our existing customers any happier with us. But it will make it easier for some of our smaller compeitors to sign up new customers." I can pretty much guarantee your meeting with the CFO will end right there. If you want networks to do this, you need to figure out a way for it to make financial sense for them to do it. So far, you haven't presented anything that would make it a win-win scenario for the ISPs and CDNs that would need to upgrade to support this. ON a separate note--NANOG mailing list admins, I'm noting that Vokan's emails just arrived a few minutes ago in my gmail inbox. However, I saw replies to his messages from others on the list yesterday, a day before they made it to the general list. Is there a backed up queue somewhere in the NANOG list processing that is delaying some messages sent to the list by up to a full day? If not, I'll just blame gmail for selectively delaying portions of NANOG for 18+ hours. ^_^; Thanks! Matt
Re: maximum ipv4 bgp prefix length of /24 ?
word salad?
example; russia decided that they are powerful enough, they are not now
eating UA. They will never stop, coz Thats how world wars start.
Now big network operators decided that they can destroy small
competitors by mergers, acquitions, restrictive or "NO" peering
policies.. and ofc price wars. You can think that We talk Network
operators aspect of world war in telecommunications.
example; some tier-1 acquires some tier-2. and FCC withdraws net
neutrality rules. IMO; you all are done, as you accepted their decisions
and didnt question them?!.. If i were in your country i would send you
best calculator available on stores for your HAPPINESS!
and you tell me to shut up! I didnt not. IMO, Everyone understood me.
Competition is good. Even if hungry people like you thinks BAD for just
yourself.
byé byé
29.09.2023 20:50 tarihinde Tom Beecher yazdı:
word salad
None of this has anything to do with why the IPv4 /24 limit is what it
is.
Good luck with your endeavors, whatever they may be.
On Fri, Sep 29, 2023 at 1:46 PM VOLKAN SALİH
wrote:
thanks for your response. Honestly thanks for everyones reponses.
comunism is the future. IMO.
tier-1 network count is decreasing. competition is always good.
while monopoly, duopoly, triopoly is not.. I dream an earth with
1000 tier-1 networks..
capitalism give people more money than they can spend in their
lifetime with their families, but it doesnt give people happiness
and health..
for example, if i were level3 or telia CEO or should I have been
major stakeholder? I would like to see 50 or 1000 more tier-1
networks competing with us.
Money is not everything. After some time capitalist bourgeois
realize that they could not "earn" health or happiness and start
spending their pennies to charities,
because if we wouldnt believe heaven and hell and purgatory, what
else we could believe? Should we believe that after death nothing
left from the earth, we worked for nothing, we laughed for
nothing, we cried for nothing, and we married for nothing?
NOPE.
Everyone is equal, in the god's/lord's/creator's vision. You need
to work on comunism instead of capitalism..
I do not care what CFO/CTO/CEO/CXO thinks! they are more miserable
than me..! I am healthy and happy. They are not. They can not be.
I just expressed my opinions, finalized them with a bad joke. ;D
You can continue your feasibility reports, net profit margin ,
return of investment calculations, but the god doesnt care IMO,
and you will not care after you are 70-80 years.old.
Best regards and wishes for you all
I guess i made myself clear.
Development is the only way. in all aspects.
29.09.2023 20:31 tarihinde Matthew Petach yazdı:
On Fri, Sep 29, 2023 at 9:42 AM VOLKAN SALİH
wrote:
[...]
I presume there would be another 50 big ASNs that belong to
CDNs. And I am pretty sure those top 100 networks can invest
in gear to support /25-/27.
Volkan,
So far, you haven't presented any good financial reason those top
100 networks should spend millions of dollars to upgrade their
networks just so your /27 can be multihomed.
Sure, they *can* invest in gear to support /25-/27; but they
won't, because there's no financial benefit for them to do so.
I know from *your* side of the table, it would make your life
better if everyone would accept /27 prefixes--multihoming for the
masses, yay!
Try standing in their shoes for a minute, though.
You need to spend tens of millions of dollars on a multi-year
refresh cycle to upgrade hundreds of routers in your global
backbone, tying up network engineering resources on upgrades that
at the end, will bring you exactly $0 in additional revenue.
Imagine you're the COO or CTO of a Fortune 500 network, and
you're meeting with your CFO to pitch this idea.
You know your CFO is going to ask one question right off the bat
"what's the timeframe for us to recoup the cost of
this upgrade?" (hint, he's looking for a number less than 40 months).
If your answer is "well, we're never going to recoup the cost.
It won't bring us any additional customers, it won't bring us any
additional revenue, and it won't make our existing customers any
happier with us. But it will make it easier for some of our
smaller compeitors to sign up new customers." I can pretty much
guarantee your meeting with the CFO will end right there.
If you want networks to do this, you need to figure out a way for
it to make financial sense for them to do it.
So far, you haven't presented anything that would make it a
win-win scenario for the ISPs and CDNs that would need to upgrad
TCP MSS clamping in PROPER way (incoming and outgoing traffic)
Dear list members, I am using PPPoE over GPON (FTTH) in Turkiye,HATAY. Provider is NetInternet Datacenter, Denizli,TR. We have a written conversation with Turk Telecom to increase MTU from 1492 to 1500 as we use Mikrotik CCR that supports 1508 bytes (baby), 9kb and 10kb jumbo frames,. I am running non-commercial R&D network for myself. They responded negative to their reseller (the datacenter). They do not provide DHCP over GPON (IPoE) or DotX. Why would I request that (1500 bytes MTU) while there is TCP MSS clamping?! Unfortunately i have come to understanding that enabling Mikrotik's TCP MSS Clamping PPP profile in addition to IPv4+IPv6 clamp-to-pmtu rule; does not work in both ways. How did I find that? Added filter rule with LOG action for packet size > 1492 or/and for TCP packets > 1452 MSS. There was lots of packets by-passing clamping. After that, I added following rules; and email-loads and page-loads are much more FASTER! without any renegotiations. //ipv6 firewall mangle add action=change-mss chain=postrouting new-mss=clamp-to-pmtu passthrough=yes protocol=tcp tcp-flags=syn add action=change-mss chain=forward new-mss=clamp-to-pmtu passthrough=yes protocol=tcp tcp-flags=syn add action=change-mss chain=output new-mss=clamp-to-pmtu passthrough=yes protocol=tcp tcp-flags=syn add action=change-mss chain=postrouting new-mss=clamp-to-pmtu passthrough=yes protocol=tcp tcp-flags=syn,!syn add action=change-mss chain=forward new-mss=clamp-to-pmtu passthrough=yes protocol=tcp tcp-flags=syn,!syn add action=change-mss chain=output new-mss=clamp-to-pmtu passthrough=yes protocol=tcp tcp-flags=syn,!syn add action=change-mss chain=postrouting new-mss=clamp-to-pmtu passthrough=yes protocol=tcp tcp-flags=syn,ack add action=change-mss chain=forward new-mss=clamp-to-pmtu passthrough=yes protocol=tcp tcp-flags=syn,ack add action=change-mss chain=output new-mss=clamp-to-pmtu passthrough=yes protocol=tcp tcp-flags=syn,ack add action=change-mss chain=postrouting new-mss=clamp-to-pmtu passthrough=yes protocol=tcp tcp-flags=syn,ack,!syn add action=change-mss chain=forward new-mss=clamp-to-pmtu passthrough=yes protocol=tcp tcp-flags=syn,ack,!syn add action=change-mss chain=output new-mss=clamp-to-pmtu passthrough=yes protocol=tcp tcp-flags=syn,ack,!syn/ //ip firewall mangle add action=change-mss chain=postrouting new-mss=clamp-to-pmtu passthrough=yes protocol=tcp tcp-flags=syn add action=change-mss chain=forward new-mss=clamp-to-pmtu passthrough=yes protocol=tcp tcp-flags=syn add action=change-mss chain=output new-mss=clamp-to-pmtu passthrough=yes protocol=tcp tcp-flags=syn add action=change-mss chain=postrouting new-mss=clamp-to-pmtu passthrough=yes protocol=tcp tcp-flags=syn,!syn add action=change-mss chain=forward new-mss=clamp-to-pmtu passthrough=yes protocol=tcp tcp-flags=syn,!syn add action=change-mss chain=output new-mss=clamp-to-pmtu passthrough=yes protocol=tcp tcp-flags=syn,!syn add action=change-mss chain=postrouting new-mss=clamp-to-pmtu passthrough=yes protocol=tcp tcp-flags=syn,ack add action=change-mss chain=forward new-mss=clamp-to-pmtu passthrough=yes protocol=tcp tcp-flags=syn,ack add action=change-mss chain=output new-mss=clamp-to-pmtu passthrough=yes protocol=tcp tcp-flags=syn,ack add action=change-mss chain=postrouting new-mss=clamp-to-pmtu passthrough=yes protocol=tcp tcp-flags=syn,ack,!syn add action=change-mss chain=forward new-mss=clamp-to-pmtu passthrough=yes protocol=tcp tcp-flags=syn,ack,!syn add action=change-mss chain=output new-mss=clamp-to-pmtu passthrough=yes protocol=tcp tcp-flags=syn,ack,!syn/ But couldn't and shouldn't all these possible with single rule? or PPP profile setting shouldnt consider ACK's and any other flags that can be added to SYN?! Thanks for reading and looking forward to HEAR feedback from you all. Regards
Re: TCP MSS clamping in PROPER way (incoming and outgoing traffic)
Thanks Mr. Brandon for the response/feedback. Rgrds 17.06.2024 22:08 tarihinde Brandon Martin yazdı: Is something out of your control also breaking PMTU discovery (e.g. blocking all ICMP traffic)? With working PMTU discovery, this issue should resolve itself in the ingress direction. You should also set the MTU properly on your PPPoE tunnel interface. If the setup inherits properly from the parent interface's MTU, this should again be automatic, but I've observed a lot of PPPoE stacks don't necessarily do that (not that I've used PPPoE in a hot minute). That will get mean PMTU discovery between things on your LAN and the Internet happens right at your Internet edge in the egress direction and therefore doesn't incur Internet latencies. If the "clamp MSS to PMTU" is working, this probably means you have it right since that's usually where the rule gets its PMTU (not actual end-to-end PMTUD), but I don't know Microtik for sure. Clamping the MSS to the known PTMU will fix the opposite direction in cases where PMTUD is broken. That's basically why it exists.
Request for Deployment of Google/YouTube Global Cache Servers in Türkiye (Istanbul, Izmir and Ankara of TURKEI)
*Subject:* Request for Deployment of Google/YouTube Global Cache Servers in Türkiye *To Whom It May Concern,* I am a government officer and a colleague of Mr. Ahmet Hamdi Atalay (ahata...@turksat.com.tr), who serves at Türksat. Currently, internet users in Türkiye experience *Google/YouTube speeds limited to approximately 15-20 Mbps*, which is significantly lower than the global standards. As Türksat personnel and civil servants committed to improving national digital infrastructure, we strongly advocate for increasing these speeds to *100-1000 Mbps levels*. *Rationale for Deployment:* Türksat has *direct connectivity with the three largest network operators in Türkiye (Türk Telekom, Vodafone TR, and Turkcell)*. Given this strategic position, we kindly request the *installation of Google/YouTube Global Cache (GGC) servers at Türksat’s network locations in Istanbul, Izmir, and Ankara*. * *Hardware and software* will be provided by Google/YouTube team/management. * *Bandwidth (IP transit)* and DECIX ISTANBUL / GIBIRIX ports /circuits will be fully covered by Türksat. We believe this collaboration will provide *substantial benefits* to both parties and the broader Turkish internet ecosystem. *Legal and Regulatory Basis* 1. *Consumer Protection Laws & Internet Rights:* * Article 57 of the *Turkish Constitution* guarantees the *right to access quality and affordable public services*, which includes internet connectivity. * According to the *Turkish Electronic Communications Law No. 5809*, service providers must ensure high-speed, uninterrupted internet access for end users. * The *EU's Open Internet Regulation (Regulation 2015/2120)* emphasizes network optimization to prevent congestion and improve consumer experience. 2. *Precedents and Global Best Practices:* * Many *IXPs (Internet Exchange Points) in Europe and North America* already host Google/YouTube caches, drastically improving performance and reducing latency. * Regulatory bodies such as the *FCC (Federal Communications Commission - USA)* and *BEREC (Body of European Regulators for Electronic Communications - EU)* support infrastructure improvements that enhance consumer digital experience. *Economic and Technical Benefits for Google* * *Cost Savings on IP Transit Fees:* o By deploying GGC servers within Türksat’s network, *Google will significantly reduce its IP transit expenses* for traffic originating from Türkiye. o Similar deployments in other regions have led to *over 40% reduction in IP transit costs* for content delivery networks. * *Lower Latency, Higher User Engagement:* o Hosting YouTube content locally will *reduce buffering times and improve video streaming quality*, leading to increased *watch time, ad impressions, and user satisfaction*. o Google’s experience in *Indonesia, Brazil, and India* has demonstrated that local caching improves performance metrics while boosting overall revenue from digital advertising. * *Regulatory and Competitive Advantages:* o Establishing cache servers in Türkiye will align *Google’s services with local digital transformation goals*, strengthening its market position against competitors. o This initiative supports *Google’s commitments to net neutrality and fair internet access*, reinforcing its positive relationship with regulators. For further discussion and technical coordination, please direct correspondence to *peer...@turksat.com.tr* with a CC to *Mr. Atalay*. We appreciate your attention to this request and look forward to a productive collaboration. *Best regards,*
Streaming Bandwidth Requirements..
Dear NANOG members, Hoping that some members working at Google/YouTube might be part of this group, I respectfully suggest adding or noting the following to YouTube's bandwidth requirements page [1]: * *8K (H.264):* 110 Mbps * *8K (H.265):* 60 Mbps [1] https://support.google.com/youtube/answer/78358?hl=en *References and Standards:* * *ITU-T H.265 (HEVC) Standard:* High Efficiency Video Coding (HEVC) significantly reduces bit rate requirements compared to H.264 while maintaining the same video quality. (Source <https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding>) * *Bitrate Requirements for 8K Video:* o A study on *8K 120Hz HEVC/H.265 encoding* indicates that the required bit rate ranges from *85–110 Mbps*. (Source <https://www.cambridge.org/core/journals/apsipa-transactions-on-signal-and-information-processing/article/video-bitrate-requirements-for-8k-120hz-hevch265-temporal-scalable-coding-experimental-study-based-on-8k-subjective-evaluations/ED85B79ECC1EC55D74B1EB4FB7F39B46>) o *H.264 encoding* generally requires higher bit rates for high resolutions, and an estimated bit rate for 8K content is around *110 Mbps*. o *H.265 (HEVC) encoding* allows for more efficient compression, reducing the required bitrate for *8K content to approximately 60 Mbps* while maintaining similar video quality. *Conclusion:* To improve the accuracy of YouTube's bandwidth requirement documentation, I propose updating the page with recommended bitrates for *8K (H.264) and 8K (H.265) video formats*. This would provide more precise information to users regarding bandwidth needs for high-resolution content delivery. Best Regards and wishes, Sincerely, Mr. Volkan SALiH +90 540 415 55 55 +90 540 489 99 99
