>> this needs publication on your adventure game of a web site, please. it
>> will seriously 'inform' some discussion going back and forth on ietf
>> lists.
>
> This is now published on RIPE Labs. For the adventurous:
> https://labs.ripe.net/Members/emileaben/ripe-atlas-packet-size-matters
some
On 31/08/2013 13:09, Randy Bush wrote:
i wonder if this is correlated with the high number of probes being
behind nats.
>>
>> Maybe this provides a bit of insight:
>> From a test last week from all RIPE Atlas probes to a single "known
>> good" MTU 1500 host I compared probes where I had b
I know I'm digging up an old thread here but I've spent some time
analyzing some of the significant changes that Apple has made to the
Facetime protocol, apparently with a huge focus on IP packet size to
avoid fragmentation issues:
http://blog.krisk.org/2013/09/apples-new-facetime-sip-perspective.
On Sep 1, 2013, at 23:11 , "Fred Baker (fred)" wrote:
>
> On Aug 27, 2013, at 12:34 AM, Owen DeLong wrote:
>
>> If I send a packet out as a legitimate series of fragments, what is the
>> chance
>> that they will get dropped somewhere in the middle of the path between the
>> emitting host and
On Aug 27, 2013, at 12:34 AM, Owen DeLong wrote:
> If I send a packet out as a legitimate series of fragments, what is the chance
> that they will get dropped somewhere in the middle of the path between the
> emitting host and the receiving host?
>
> To my thinking, the answer to that question
On 31/08/2013 13:13, Randy Bush wrote:
> could you please test with ipv6?
This is what I see for various IPv6 payloads (large ICMPv6 echo
requests) from all RIPE Atlas probes that where available at the time to
a single "known good" MTU 1500 destination:
plenfail% nr_probes
100 9.64
>>> i wonder if this is correlated with the high number of probes being
>>> behind nats.
>
> Maybe this provides a bit of insight:
> From a test last week from all RIPE Atlas probes to a single "known
> good" MTU 1500 host I compared probes where I had both a ping test with
> ipv4.len 1020 and ipv
could you please test with ipv6?
thanks!
randy
erprint the probes to figure out if this was true.
>
> If we will rerun the experiments in the future, we should spent more
> effort into identifying the router/middlebox that is giving the IP
> fragmentation problems (drops or blocking PMTUD ICMP).
Maybe this provides a bit of insight:
ture, we should spent more
effort into identifying the router/middlebox that is giving the IP
fragmentation problems (drops or blocking PMTUD ICMP).
-- Benno
--
Benno J. Overeinder
NLnet Labs
http://www.nlnetlabs.nl/
> In a study using the RIPE Atlas probes, we have used a heuristic to
> figure out where the fragments where dropped. And from the Atlas
> probes where IP fragments did not arrive, there is a high likelihood
> the problem is with the last hop to the Atlas probe.
i wonder if this is correlated wit
Mark Andrews wrote:
> Ensure that the firealls at both ends pass ICMP/ICMPv6 PTB. Only
> idiots block all ICMP/ICMPv6. Yes there are a lot of idiots in the
> world.
The worst idiots are people who designed ICMPv6 [RFC2463] as:
(e.2) a packet destined to an IPv6 multicast address (ther
On Aug 29, 2013, at 18:15 , Mark Andrews wrote:
>
> In message
> .com>, Christopher Palmer writes:
>> This is what I'm concerned about:
>>
>> """
>> 1. If I originate IP packet fragments, such as an 8000 byte NFS packet
>> broken into 1500 byte fragments, what's the probability of some host
elpful.
>
> -Original Message-
> From: wher...@gmail.com [mailto:wher...@gmail.com] On Behalf Of William
> Herrin
> Sent: Tuesday, August 27, 2013 10:45 AM
> To: Christopher Palmer
> Cc: North American Network Operators' Group
> Subject: Re: IP Fragmentation - Not rel
thanks to everyone who has sent thoughts already, really quite helpful.
-Original Message-
From: wher...@gmail.com [mailto:wher...@gmail.com] On Behalf Of William Herrin
Sent: Tuesday, August 27, 2013 10:45 AM
To: Christopher Palmer
Cc: North American Network Operators' Group
Subject:
On 29/08/2013 04:22, Owen DeLong wrote:
> Has the path MTU been measured for all vantage point pairs?
I didn't, but see
http://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf
Fig 23 (page 24) for path MTU data from roughly a year ago (thanks
Benno for posting that link).
On 8/27/13 4:04 PM, Leo Bicknell wrote:
> I'm pretty sure the failure rate is higher, and here's why.
>
> The #1 cause of fragments being dropped is firewalls. Too many
> admins configuring a firewall do not understand fragments or how to
> properly put them in the rules.
>
> Where do firewalls
Has the path MTU been measured for all vantage point pairs?
Is it known to be 1500 or just the end-point MTUs?
That could affect your results very differently.
Owen
On Aug 28, 2013, at 02:26 , Emile Aben wrote:
> On 28/08/2013 08:05, Tore Anderson wrote:
>> * Owen DeLong
>>
>>> On Aug 27, 20
On 28/08/2013 08:05, Tore Anderson wrote:
> * Owen DeLong
>
>> On Aug 27, 2013, at 07:33 , valdis.kletni...@vt.edu wrote:
>>
>>> Saku Ytti and Emile Aben have numbers that say otherwise. And there must
>>> be a significantly bigger percentage of failures than "pretty close to 0",
>>> or Path MTU
* Owen DeLong
> On Aug 27, 2013, at 07:33 , valdis.kletni...@vt.edu wrote:
>
>> Saku Ytti and Emile Aben have numbers that say otherwise. And there must
>> be a significantly bigger percentage of failures than "pretty close to 0",
>> or Path MTU Discovery wouldn't have a reputation of being next
On Aug 27, 2013, at 07:33 , valdis.kletni...@vt.edu wrote:
> On Tue, 27 Aug 2013 00:34:57 -0700, Owen DeLong said:
>> That's a lot of questions he didn't ask.
>
> This isn't your first rodeo. You should know by now that the question
> actually asked, the question *meant* to be asked, and the qu
On Mon, Aug 26, 2013 at 8:01 PM, Christopher Palmer
wrote:
> What is the probability that a random path between two Internet
> hosts will traverse a middlebox that drops or otherwise barfs on
> fragmented IPv4 packets?
Hi Christopher,
I think there might be three rather different questions here:
On 8/27/2013 10:04 AM, Leo Bicknell wrote:
>
> On Aug 27, 2013, at 6:24 AM, Saku Ytti wrote:
>
>> On (2013-08-27 10:45 +0200), Emile Aben wrote:
>>
224 vantage points, 10 failed.
>>>
>>> 48 byte ping:42 out of 3406 vantage points fail (1.0%)
>>> 1473 byte ping: 180 out of 3540 vantage poi
And then you have other issues like networks that arbitrarily set DF on all
packets passing through them. That burnt a good three days of my life back
in the day.
-Blake
On Tue, Aug 27, 2013 at 9:33 AM, wrote:
> On Tue, 27 Aug 2013 00:34:57 -0700, Owen DeLong said:
> > That's a lot of question
On Tue, 27 Aug 2013 00:34:57 -0700, Owen DeLong said:
> That's a lot of questions he didn't ask.
This isn't your first rodeo. You should know by now that the question
actually asked, the question *meant* to be asked, and the question that
actually needed answering are often 3 different things.
>
On Aug 27, 2013, at 6:24 AM, Saku Ytti wrote:
> On (2013-08-27 10:45 +0200), Emile Aben wrote:
>
>>> 224 vantage points, 10 failed.
>>
>> 48 byte ping:42 out of 3406 vantage points fail (1.0%)
>> 1473 byte ping: 180 out of 3540 vantage points fail (5.1%)
>
> Nice, it's starting to almost
On (2013-08-27 10:45 +0200), Emile Aben wrote:
> > 224 vantage points, 10 failed.
>
> 48 byte ping:42 out of 3406 vantage points fail (1.0%)
> 1473 byte ping: 180 out of 3540 vantage points fail (5.1%)
Nice, it's starting to almost sound like data rather than anecdote, both
tests implicate 4
Christopher Palmer wrote:
>
> What is the probability that a random path between two Internet hosts
> will traverse a middlebox that drops or otherwise barfs on fragmented
> IPv4 packets?
This question is important for large EDNS packets so you'll find some
recent
Christopher Palmer wrote:
>
> What is the probability that a random path between two Internet hosts
> will traverse a middlebox that drops or otherwise barfs on fragmented
> IPv4 packets?
This question is important for large EDNS packets so you'll find some
recent practical investigations from th
On 27/08/2013 08:55, Saku Ytti wrote:
> On (2013-08-27 00:01 +), Christopher Palmer wrote:
>
>> If anyone has any data or anecdotes, please feel free to send an off-list
>> email or whatever.
>
> [y...@ytti.fi ~]% ssh ring ring-all -t90 ping -s 1473 -c2 -w3 ip.fi|pastebinit
> http://p.ip.fi
On Aug 26, 2013, at 22:02 , valdis.kletni...@vt.edu wrote:
> On Tue, 27 Aug 2013 00:01:45 -, Christopher Palmer said:
>> What is the probability that a random path between two Internet hosts will
>> traverse a middlebox that drops or otherwise barfs on fragmented IPv4
>> packets?
>
> THe fa
On (2013-08-27 00:01 +), Christopher Palmer wrote:
> If anyone has any data or anecdotes, please feel free to send an off-list
> email or whatever.
[y...@ytti.fi ~]% ssh ring ring-all -t90 ping -s 1473 -c2 -w3 ip.fi|pastebinit
http://p.ip.fi/KA7N
[ytti@sci ~]% curl -s http://p.ip.fi/KA7N|g
On Tue, 27 Aug 2013 00:01:45 -, Christopher Palmer said:
> What is the probability that a random path between two Internet hosts will
> traverse a middlebox that drops or otherwise barfs on fragmented IPv4 packets?
THe fact you're posting indicates that you already know the practical
answer: "
I am trolling for information/community wisdom.
What is the probability that a random path between two Internet hosts will
traverse a middlebox that drops or otherwise barfs on fragmented IPv4 packets?
If anyone has any data or anecdotes, please feel free to send an off-list email
or whatever.
The application is set to
> use an 8k buffer and therefore results in IP fragmentation when datagrams are
> transmitted. The application is sensitive to any latency or data loss (of
> course) and uses a proprietary mechanism to create TCP-like retransmissions
> in case there is any act
To all,
I am running a Windows based high performance computing application that uses
"reliable" multicast (29West) on a gigabit LAN. All systems are logically on
the same VLAN and even on the same physical switch The application is set to
use an 8k buffer and therefore res
On Fri, 29 Aug 2008 05:44:28 +0530, Glen Kent said:
> I understand, but the question is what if they dont?
If it's an alleged router, and it doesn't know how to frag a packet, it's
probably so brain-damaged that it can't send a recognizable 'Frag Needed'
ICMP back either. At that point, all bets
On 29 aug 2008, at 2:14, Glen Kent wrote:
I understand, but the question is what if they dont?
Then the internet breaks.
again with the MTU reported in the ICMP error message, or is the ICMP
error message silently ignored?
Glen
On 8/29/08, Tony Li <[EMAIL PROTECTED]> wrote:
>
>
> |OK, so what happens if a transit router does not support IP
> |fragmentation
>
>
> All IPv4 routers are suppos
|OK, so what happens if a transit router does not support IP
|fragmentation
All IPv4 routers are supposed to support fragmentation per RFC 1812 (Router
Requirements), section 4.2.2.7.
Tony
At 08:44 p.m. 28/08/2008, Glen Kent wrote:
I understand that routers usually must send this error only when a
fragmentation is required and they recieve a packet with DF bit set.
However, in this case this router would drop the packet (for it doesnt
support fragmentation) and sending an ICMP err
the DF is set and one of the routes
> requires fragmentation).
OK, so what happens if a transit router does not support IP
fragmentation and it receives a packet which is bigger than the
outgoing link's MTU. Should it simply drop the packet or proactively
send an ICMP Dest Unreachable e
Sam Stickland writes:
> Iljitsch van Beijnum wrote:
>> Yet all OSes have it enabled and there is no fallback to
>> fragmentation in PMTUD: if your system doesn't get the ICMP
>> messages, your session is dead in the water.
>>
> Windows Vista/2007 has black hole detection enabled by default. It's
>
On 25 aug 2008, at 12:27, Fernando Gont wrote:
http://support.microsoft.com/kb/925280
IPv4 minimum MTU is 68 bytes,
That's kind of like "a human being can live without food for four to
six weeks". It's not a recommendation.
536 is the minimum fragment re-assembly buffer size. Falling ba
At 07:07 p.m. 20/08/2008, Sam Stickland wrote:
Yet all OSes have it enabled and there is no fallback to
fragmentation in PMTUD: if your system doesn't get the ICMP
messages, your session is dead in the water.
Windows Vista/2007 has black hole detection enabled by default. It's
not massively el
Iljitsch van Beijnum wrote:
On 20 aug 2008, at 20:04, [EMAIL PROTECTED] wrote:
Hypothetically true. Unfortunately, enough places do bozo
firewalling and drop
the ICMP Frag Needed packets to severely limit the utility of PMTU
Discovery.
Yet all OSes have it enabled and there is no fallback t
PROTECTED]
Sent: Wednesday, August 20, 2008 2:11 PM
To: Glen Kent; OPS Gurus
Subject: RE: IP Fragmentation
Glen,
With the v4 networks that I have worked on in the past, they did not do end to
end MTU discovery before sending packets. The TTL had to be set appropriately
so that if you had low speed
On 2008/08/20 08:04 PM [EMAIL PROTECTED] wrote:
On Wed, 20 Aug 2008 21:43:44 +0530, Glen Kent said:
Do transit routers in the wild actually get to do IP fragmentation
these days? I was wondering if routers actually do it or not, because
the source usually discovers the path MTU and sends its
From: John Lee [EMAIL PROTECTED]
Sent: Wednesday, August 20, 2008 2:10 PM
To: Glen Kent; OPS Gurus
Subject: RE: IP Fragmentation
Glen,
With the v4 networks that I have worked on in the past, they did not do end to
end MTU discovery before sending packets. The TTL
: Wednesday, August 20, 2008 12:13 PM
To: OPS Gurus
Subject: IP Fragmentation
Hi,
Do transit routers in the wild actually get to do IP fragmentation
these days? I was wondering if routers actually do it or not, because
the source usually discovers the path MTU and sends its data with the
least supported
On 20 aug 2008, at 20:04, [EMAIL PROTECTED] wrote:
Hypothetically true. Unfortunately, enough places do bozo
firewalling and drop
the ICMP Frag Needed packets to severely limit the utility of PMTU
Discovery.
Yet all OSes have it enabled and there is no fallback to fragmentation
in PMTUD:
On Wed, 20 Aug 2008 21:43:44 +0530, Glen Kent said:
> Do transit routers in the wild actually get to do IP fragmentation
> these days? I was wondering if routers actually do it or not, because
> the source usually discovers the path MTU and sends its data with the
> least supported
Leo Bicknell wrote:
In a message written on Wed, Aug 20, 2008 at 09:43:44PM +0530, Glen Kent wrote:
Do transit routers in the wild actually get to do IP fragmentation
these days? [...]
Yes.
A GigE jumbo frames host (9120) to a standard POS interface (4420)
to a DS3 customer (1500) happens
In a message written on Wed, Aug 20, 2008 at 09:43:44PM +0530, Glen Kent wrote:
> Do transit routers in the wild actually get to do IP fragmentation
> these days? I was wondering if routers actually do it or not, because
> the source usually discovers the path MTU and sends its data
Glen Kent wrote:
Do transit routers in the wild actually get to do IP fragmentation
these days? I was wondering if routers actually do it or not, because
the source usually discovers the path MTU and sends its data with the
least supported MTU. Is this true?
I believe that is only true for TCP
Hi,
Do transit routers in the wild actually get to do IP fragmentation
these days? I was wondering if routers actually do it or not, because
the source usually discovers the path MTU and sends its data with the
least supported MTU. Is this true?
Even if this is, then this would break for
56 matches
Mail list logo
