> -Original Message-
> From: Perry Lorier [mailto:[EMAIL PROTECTED]
> Sent: Monday, August 01, 2005 4:24 AM
> Cc: IETF IPv6 Mailing List
> Subject: Re: jumbo frame of GbE and IPv6 -- A proposal
>
> (Sorry for being late on the replies, been busy recently :)
&g
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 ma
(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
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 receiv
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 br
> > 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 tunn
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 th
> > 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 com
[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 no
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 to
>>> 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
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 simila
> 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 similar
> to survive
I'd add to this lis
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 paddi
>> 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 impo
15 matches
Mail list logo
