(Sorry for being late on the replies, been busy recently :)
When a tunnel is used, there may be many L2 segments (connected by
L2 switches) with diverse MTUs separating the tunnel endpoints in what
otherwise appears as a single-hop to L3. And, the set of L2 segments
will often be different in
Mark Smith wrote:
Hi Iljitsch, Perry,
I'll admit I haven't been fully following your thread of discussion,
I've been a bit busy on some other things (another reason why I like the
simple solution - less thinking :-) )
Something to keep in mind for your solution. TCP announces the maximum
[Bugger! Lost the reply I was writing for this! ]
Packet rate however starts becoming a problem at faster speeds, at gige
it starts becoming a problem for hosts to deal with unless they are
careful. And not all networks are fast, 3G networks are becoming more
prevalent. We should not waste
And why not NS?
Because when A talks to B, you want A to do the MTU discovery
and for B
to learn the MTU too, but you don't want both sending MTU
probes, only
one of them needs to do so.
Disagree - PMTU probing is a unidirectional endeavor since the path
from A-B may have completely
Templin, Fred L wrote:
And why not NS?
Because when A talks to B, you want A to do the MTU discovery
and for B
to learn the MTU too, but you don't want both sending MTU
probes, only
one of them needs to do so.
Disagree - PMTU probing is a unidirectional endeavor since the path
from A-B
Disagree - PMTU probing is a unidirectional endeavor since the path
from A-B may have completely different characteristics than B-A.
But this isn't on a path, it's on the same L2. L2 traditionally is a
spanning tree, or broadcast media so the assumption seems to hold.
When a tunnel is
Thus spake Perry Lorier [EMAIL PROTECTED]
Templin, Fred L wrote:
Disagree - PMTU probing is a unidirectional endeavor since the path
from A-B may have completely different characteristics than B-A.
But this isn't on a path, it's on the same L2. L2 traditionally is a
spanning tree, or
Hi Iljitsch, Perry,
I'll admit I haven't been fully following your thread of discussion,
I've been a bit busy on some other things (another reason why I like the
simple solution - less thinking :-) )
Something to keep in mind for your solution. TCP announces the maximum
segment size it can
1. do not impede 1500-byte operation
2. discover and utilize jumboframe capability where possible
3. discover and utilize (close to) the maximum MTU
4. recover from sudden MTU reductions fast enough for TCP and similar
to survive
5. Must be fully automatic and not require any admin
On 26-jul-2005, at 13:46, Perry Lorier wrote:
6. Minimise the resources used.
Agree, except that packets are cheap on a 1000 Mbps LAN, so those
don't
count much towards 6.
Packet rate however starts becoming a problem at faster speeds, at
gige
it starts becoming a problem for hosts
On 23-jul-2005, at 17:12, Perry Lorier wrote:
Before two hosts can transmit packets on Ethernet they have to undergo
neighbour solicitation to find the remote ends hardware address
anyway.
Right.
When you send the neighbour solicitation you could pad the packet out
with multiple MTU
I agree with pretty much everything said here, so I'll just snip it
I think our requirements are:
1. do not impede 1500-byte operation
2. discover and utilize jumboframe capability where possible
3. discover and utilize (close to) the maximum MTU
4. recover from sudden MTU reductions
On 24-jul-2005, at 15:16, Perry Lorier wrote:
I think our requirements are:
1. do not impede 1500-byte operation
2. discover and utilize jumboframe capability where possible
3. discover and utilize (close to) the maximum MTU
4. recover from sudden MTU reductions fast enough for TCP and
The hole is that there may be an L2 device in the middle which has a
lower MTU than the end hosts. The neighbor MTU is an upper bound,
but it's not guaranteed to work -- you need to probe to see what
really works.
(Layer 1 devices can also impose MTU limits.)
It's important to
14 matches
Mail list logo
