> -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
Stephen,
> >> > Matt Mathis in draft-ietf-pmtud-method-04.txt and Fred Templin
> >> > in draft-templin-ipvlx-02.txt.
> >>
> >> I don't really see how those apply.
> >
> > Only because from what I remember of Matt's draft, and what Fred
> > said about his, they perform some sort of MTU discovery w
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
Thus spake "Mark Smith" <[EMAIL PROTECTED]>
On Tue, 26 Jul 2005 13:05:31 +0200
Iljitsch van Beijnum <[EMAIL PROTECTED]> wrote:
You mean: if I hook up two hosts that support 9k jumboframes to a
cheap unmanaged 10/100 switch (all out of the box) and it doesn't
work, I have to go in and reconfigure
Iljitsch,
> > Matt Mathis in
> > draft-ietf-pmtud-method-04.txt and Fred Templin in
> > draft-templin-ipvlx-02.txt.
>
> I don't really see how those apply.
They apply in any case where IPv6-in-IPv4 virtual links
are used instead of native IPv6 links. Where are we at
in the decision process for n
Hi Mark,
It's clear that we're thinking from two very different starting
points. You want to make a few very small changes to the current way
of using jumboframes, all the while accepting all the current
limitations that make that virtually nobody uses them.
What I want to do is remove th
In your previous mail you wrote:
I think there are three ways for us.
1) Do nothing. Jumbo Frames is an illegal specification for IEEE
802.3, and there is no de facto frame size also. Wait until IEEE
will move, or a de facto standard will be made.
=> this is not accept
we're posing on networks equipments with this 1500B tinygrams.
Cheers,
Nuno M. Garcia,
Siemens SA
Portugal
-Mensagem original-
De: [EMAIL PROTECTED] em nome de Perry Lorier
Enviada: ter 26-07-2005 14:22
Para:
Cc: ipv6@ietf.org
Assunto
>
> If you enable jumbo frames on end-nodes without a layer 2 infrastructure
> that supports them, then you get what you deserve - a network that won't
> work. The solution of course is go back to standard size frames or buy
> jumbo capable layer 2 infrastructure and enable it. I think it's reall
Hi Iljitsch,
On Tue, 26 Jul 2005 13:05:31 +0200
Iljitsch van Beijnum <[EMAIL PROTECTED]> wrote:
> On 26-jul-2005, at 4:41, Mark Smith wrote:
>
> > I'd like to suggest a two phased development approach, based on
> > whether
> > layer 2 can be assumed to fully support the larger MTUs or not (I
>>> 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 26-jul-2005, at 4:41, Mark Smith wrote:
I'd like to suggest a two phased development approach, based on
whether
layer 2 can be assumed to fully support the larger MTUs or not (I
think
the following is also probably a summary of the couple of threads of
discussion in the emails of the last
On Tue, Jul 26, 2005 at 08:41:39PM +1200, Perry Lorier wrote:
>
> > I'd like to suggest a two phased development approach, based on whether
> > layer 2 can be assumed to fully support the larger MTUs or not (I think
> > the following is also probably a summary of the couple of threads of
> > discu
> I'd like to suggest a two phased development approach, based on whether
> layer 2 can be assumed to fully support the larger MTUs or not (I think
> the following is also probably a summary of the couple of threads of
> discussion in the emails of the last couple of days) :
>
> (1) Making the as
> Thinking a bit more about this: ethernet rules the world
> right now, and I see few competitors on the horizon. Although
> an ethernet switch detects attachment to a port and even
> negotiates a few capabilities, there is no mechanism to
> furter distribute the information learned that way
Hi Bob, Iljitsch,
On Sat, 23 Jul 2005 17:17:25 -0700
Bob Hinden <[EMAIL PROTECTED]> wrote:
> Iljitsch,
>
> At 05:57 PM 07/22/2005, Iljitsch van Beijnum wrote:
> >On 22-jul-2005, at 22:18, Bob Hinden wrote:
> >
> >>In my personal view, having devices on shared media with different
> >>MTU's is ju
On 24-jul-2005, at 2:17, Bob Hinden wrote:
Don't forget that management issues in layer 2 networks (= a single
layer 3 subnet) are very different from those on the global internet:
most layer 2 networks are managed by a single organization. Since we
had the hubris to think we could do PMTUD for
Fred,
> The suggestion actually comes from Matt's document, I just
> pointed it
> out and suggested a simple first-burst implementation.
>http://www.ietf.org/internet-drafts/draft-ietf-pmtud-method-04.txt
>"Path MTU Discovery", Matt Mathis, 22-Feb-05
Section 4.2 of: 'draft-templin-ip
Iljitsch,
At 05:57 PM 07/22/2005, Iljitsch van Beijnum wrote:
On 22-jul-2005, at 22:18, Bob Hinden wrote:
In my personal view, having devices on shared media with different
MTU's is just a bad idea. Trying to get it to work is complicated
and I think it will have lots of nasty failure cases.
On 25-jul-2005, at 12:02, Ryota Hirose wrote:
In my personal view, having devices on shared media with different
MTU's is
just a bad idea.
I think so, but in a real world, such bad ideas are often accepted.
:-)
Thinking a bit more about this: ethernet rules the world right now,
and I s
Hi,
>From: Bob Hinden <[EMAIL PROTECTED]>
>Date: Fri, 22 Jul 2005 13:18:24 -0700
> In my personal view, having devices on shared media with different MTU's is
> just a bad idea.
I think so, but in a real world, such bad ideas are often accepted.
In the IPv4 environment, MTU problem is more sim
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
On Sat, 23 Jul 2005 14:16:46 -0500
"Stephen Sprunk" <[EMAIL PROTECTED]> wrote:
> Thus spake "Mark Smith" <[EMAIL PROTECTED]>
> > On Fri, 22 Jul 2005 13:20:40 -0500
> > "Stephen Sprunk" <[EMAIL PROTECTED]> wrote:
> >> The hole is that there may be an L2 device in the middle which has
> >> a lower M
Thus spake "Iljitsch van Beijnum" <[EMAIL PROTECTED]>
On 22-jul-2005, at 20:20, Stephen Sprunk wrote:
Thinking about this a bit more, this could probably be fairly easy to
achieve by creating a "onlink-MRU" or "interface-MRU" option for ND
Neighbour Advertisements.
If there aren't any big hol
Thus spake "Mark Smith" <[EMAIL PROTECTED]>
On Fri, 22 Jul 2005 13:20:40 -0500
"Stephen Sprunk" <[EMAIL PROTECTED]> wrote:
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 -- yo
Perhaps this wheel has been invented before? This sounds like MTU
discovery. RFC 1063 ??
Mark Smith wrote:
> Hi Stephen,
>
> On Fri, 22 Jul 2005 13:20:40 -0500
> "Stephen Sprunk" <[EMAIL PROTECTED]> wrote:
>
>
>>Thus spake "Mark Smith" <[EMAIL PROTECTED]>
>>
>>>Thinking about this a bit more, t
Hi Stephen,
On Fri, 22 Jul 2005 13:20:40 -0500
"Stephen Sprunk" <[EMAIL PROTECTED]> wrote:
> Thus spake "Mark Smith" <[EMAIL PROTECTED]>
> > Thinking about this a bit more, this could probably be fairly easy to
> > achieve by creating a "onlink-MRU" or "interface-MRU" option for ND
> > Neighbour
On Fri, 22 Jul 2005 14:00:40 -0700
Fred Baker <[EMAIL PROTECTED]> wrote:
> In my personal view, networks like this are a fact of life. One
> frequently is handed things by disparate people with disparate
> budgets, responsibilities, and requirements. For example, perhaps IT
> provides the sw
>> 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
On 22-jul-2005, at 22:18, Bob Hinden wrote:
In my personal view, having devices on shared media with different
MTU's is just a bad idea. Trying to get it to work is complicated
and I think it will have lots of nasty failure cases. If one wants
to have mixed speeds (like the example above
On 22-jul-2005, at 20:20, Stephen Sprunk wrote:
Thinking about this a bit more, this could probably be fairly easy to
achieve by creating a "onlink-MRU" or "interface-MRU" option for ND
Neighbour Advertisements.
If there aren't any big holes in what I'm suggesting, I'm willing to
spend some t
In my personal view, networks like this are a fact of life. One
frequently is handed things by disparate people with disparate
budgets, responsibilities, and requirements. For example, perhaps IT
provides the switch, the router is what the managed-service ISP
installed several years ago and
Hi,
BTW, suppose following netowrk.
Internet
|
ROUTER
|
| 100BASE-TX / MTU=1500
|
GbE-SWITCH
| |
| | 1000BASE-T / MTU=9018
| |
HOST1 HOST2
HOST1, HOST2 and GbE-SWITCH s
Actually, I should think 1280 would be fine for both. The issue tends
to be IPSEC tunnel mode and other tunneling implementations in the
path in between, otherwise I would say "ip data size == 1500". 576
byte frames are a leftover from ARPANET IMPs and Fuzzballs...
The suggestion actually c
Thus spake "Mark Smith" <[EMAIL PROTECTED]>
Thinking about this a bit more, this could probably be fairly easy to
achieve by creating a "onlink-MRU" or "interface-MRU" option for ND
Neighbour Advertisements. There'd need to be some logic in how a
sending node selects the size of the packets that
The author of the RFC has clarified (personal communication,
posted with permission) that the intention was never to prohibit
jumbo frames, but rather:
It is only supposed to mean that Router Advertisements cannot
increase the MTU above whatever it was otherwise believed to be,
and that in t
On Fri, 22 Jul 2005 15:09:42 +0930
Mark Smith <[EMAIL PROTECTED]> wrote:
> On Fri, 22 Jul 2005 14:20:37 +0930
> Mark Smith <[EMAIL PROTECTED]> wrote:
>
> > Hi,
> >
> > On Fri, 22 Jul 2005 10:32:48 +0900 (JST)
> > Ryota Hirose <[EMAIL PROTECTED]> wrote:
> >
> > > Hi,
> > >
> > > >From: Iljitsch
On Fri, 22 Jul 2005 14:20:37 +0930
Mark Smith <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On Fri, 22 Jul 2005 10:32:48 +0900 (JST)
> Ryota Hirose <[EMAIL PROTECTED]> wrote:
>
> > Hi,
> >
> > >From: Iljitsch van Beijnum <[EMAIL PROTECTED]>
> > >Date: Thu, 21 Jul 2005 10:19:56 +0200
> >
> > > My common
Hi,
On Fri, 22 Jul 2005 10:32:48 +0900 (JST)
Ryota Hirose <[EMAIL PROTECTED]> wrote:
> Hi,
>
> >From: Iljitsch van Beijnum <[EMAIL PROTECTED]>
> >Date: Thu, 21 Jul 2005 10:19:56 +0200
>
> > My common sense tells me that the authors of RFC 2464 didn't consider
> > the case where the MTU would
Hi,
>From: Iljitsch van Beijnum <[EMAIL PROTECTED]>
>Date: Thu, 21 Jul 2005 10:19:56 +0200
> My common sense tells me that the authors of RFC 2464 didn't consider
> the case where the MTU would legitimately be larger than 1500 bytes.
> They did consider the case where router advertisements co
On 21-jul-2005, at 1:01, Ryota Hirose wrote:
As I read it, RFC2464 says that the maximum *default* MTU is 1500,
and, anything larger than that must be manually configured. It
doesn't say that it is prohibited.
RFC2464 says as following:
This size may be reduced by a Router Ad
Hi,
>From: Ryota Hirose <[EMAIL PROTECTED]>
>Date: Thu, 21 Jul 2005 08:01:52 +0900 (JST)
> Please refer RFC2467, which is about FDDI. FDDI's MTU is variable by
Please refer RFC2497 also. It is about ARCnet. ARCnet's maximum MTU
is 60480, but RFC2497 says that it is impractical, so provides tha
Hi,
>From: Hugh LaMaster <[EMAIL PROTECTED]>
>Date: Wed, 20 Jul 2005 10:58:20 -0700
> As I read it, RFC2464 says that the maximum *default* MTU is 1500,
> and, anything larger than that must be manually configured. It
> doesn't say that it is prohibited.
RFC2464 says as following:
Ryota Hirose wrote:
> Hi IPv6 hackers,
>
> Recent GbE NICs or GbE switches support Jumbo Frames, but RFC2464
> provides that the maximum MTU of an Ethernet is 1500. So we cannot
> use the Jumbo Frames for IPv6.
As I read it, RFC2464 says that the maximum *default* MTU is 1500,
and, anything larg
54 matches
Mail list logo
