On 10-apr-2007, at 18:12, David W. Hankins wrote:
IPv6 has had operating system and router support for years.
I'd have to object with such a blanket statement.
I have a Cisco 2500 with software from 1999 and a Windows XP box with
software from 2001, both supporting IPv6, sitting here...
Mikael Abrahamsson wrote:
>
> On Wed, 11 Apr 2007, Frank Bulk wrote:
>
>> It truly is a wonder that Comcast doesn't apply DOCSIS config file
>> filters
>> on their consumer accounts, leaving just the IPs of their email servers
>> open. Yes, it would take an education campaign on their part for al
Dear NANOGers,
It irks me that today, the effective MTU of the internet is 1500
bytes, while more and more equipment can handle bigger packets.
What do you guys think about a mechanism that allows hosts and
routers on a subnet to automatically discover the MTU they can use
towards other
:-> "Iljitsch" == Iljitsch van Beijnum <[EMAIL PROTECTED]> writes:
> Dear NANOGers,
> It irks me that today, the effective MTU of the internet is 1500
> bytes, while more and more equipment can handle bigger packets.
> What do you guys think about a mechanism that allows hosts a
Citando Frank Bulk <[EMAIL PROTECTED]>:
" but imagine how much work it
would save their abuse department in the long run"
I think that Comcast trouble isn't has much has the company's affected I keep
the idea that the best is to rate limit incoming connections and a lot of
filtering to preven
On 12-apr-2007, at 12:02, Pierfrancesco Caci wrote:
wouldn't that work only if the switch in the middle of your neat
office lan is a real switch (i.e. not flooding oversize packets to
hosts that can't handle them, possibly crashing their NIC drivers) and
it's itself capable of larger MTUs?
We
On (2007-04-12 11:20 +0200), Iljitsch van Beijnum wrote:
> What do you guys think about a mechanism that allows hosts and
> routers on a subnet to automatically discover the MTU they can use
> towards other systems on the same subnet, so that:
> 1. It's no longer necessary to limit the subne
On Thu, Apr 12, 2007 at 01:03:45PM +0200, Iljitsch van Beijnum wrote:
>
> On 12-apr-2007, at 12:02, Pierfrancesco Caci wrote:
>
> >wouldn't that work only if the switch in the middle of your neat
> >office lan is a real switch (i.e. not flooding oversize packets to
> >hosts that can't handle the
On Thu, 12 Apr 2007, Saku Ytti wrote:
IXP peeps, why are you not offering high MTU VLAN option?
Netnod in Sweden offer MTU 4470 option.
Otoh it's not so easy operationally since for instance Juniper and Cisco
calculates MTU differently.
But I don't really see it beneficial to try to up th
* [EMAIL PROTECTED] (Mikael Abrahamsson) [Thu 12 Apr 2007, 14:07 CEST]:
On Thu, 12 Apr 2007, Saku Ytti wrote:
IXP peeps, why are you not offering high MTU VLAN option?
Biggest benefit would be if the transport network people run PPPoE and
other tunneled traffic over, would allow for whatever M
On Thu, 12 Apr 2007 11:20:18 +0200
Iljitsch van Beijnum <[EMAIL PROTECTED]> wrote:
>
> Dear NANOGers,
>
> It irks me that today, the effective MTU of the internet is 1500
> bytes, while more and more equipment can handle bigger packets.
>
> What do you guys think about a mechanism that allows
I agree. The throughput gains are small. You're talking about a
difference between a 4% header overhead versus a 1% header overhead
(for TCP).
One could argue a decreased pps impact on intermediate systems, but
when factoring in the existing packet size distribution on the
Internet and th
* Steven M. Bellovin:
> A few years ago, the IETF was considering various jumbogram options.
> As best I recall, that was the official response from the relevant
> IEEE folks: "no". They're concerned with backward compatibility.
Gigabit ethernet has already broken backwards compatibility and i
On 12-apr-2007, at 16:04, Gian Constantine wrote:
I agree. The throughput gains are small. You're talking about a
difference between a 4% header overhead versus a 1% header overhead
(for TCP).
6% including ethernet overhead and assuming the very common TCP
timestamp option.
One could a
On Thu, 12 Apr 2007 16:12:43 +0200
Florian Weimer <[EMAIL PROTECTED]> wrote:
> * Steven M. Bellovin:
>
> > A few years ago, the IETF was considering various jumbogram options.
> > As best I recall, that was the official response from the relevant
> > IEEE folks: "no". They're concerned with back
Dear all,
This is to let you know that I have resuscitated the DNSBL which lists
all IPv4 space currently announced by ASN and country-code.
For those of you who remember, I closed it down for personal reasons 18
months ago. The current version is light-coded, easy to maintain and
almost fully-a
On 12-apr-2007, at 15:26, Steven M. Bellovin wrote:
Last I heard, the IEEE won't go along, and they're the ones who
standardize 802.3.
I knew there was a reason we use ethernet II rather than IEEE 802.3
for IP. :-)
A few years ago, the IETF was considering various jumbogram options.
As
I think it's a great idea operationally, less work for the routers and
more efficient use of bandwidth. It would also be useful to devise some
way to at least partially reassemble fragmented frames at links capable of
large MTU's. Since most PC's are on a subnet with a MTU of 1500 (or 1519)
* Steven M. Bellovin:
> On Thu, 12 Apr 2007 16:12:43 +0200
> Florian Weimer <[EMAIL PROTECTED]> wrote:
>
>> * Steven M. Bellovin:
>>
>> > A few years ago, the IETF was considering various jumbogram options.
>> > As best I recall, that was the official response from the relevant
>> > IEEE folks:
Niels Bakker wrote:
>
> * [EMAIL PROTECTED] (Mikael Abrahamsson) [Thu 12 Apr 2007, 14:07 CEST]:
>> On Thu, 12 Apr 2007, Saku Ytti wrote:
>>> IXP peeps, why are you not offering high MTU VLAN option?
>> Biggest benefit would be if the transport network people run PPPoE and
>> other tunneled traffi
On Apr 12, 2007, at 10:04 AM, Gian Constantine wrote:
I agree. The throughput gains are small. You're talking about a
difference between a 4% header overhead versus a 1% header overhead
(for TCP).
One of the "benefits" of larger MTU is that, during the additive
increase phase, or after r
On (2007-04-12 16:28 +0200), Iljitsch van Beijnum wrote:
>
> On 12-apr-2007, at 16:04, Gian Constantine wrote:
>
> >I agree. The throughput gains are small. You're talking about a
> >difference between a 4% header overhead versus a 1% header overhead
> >(for TCP).
>
> 6% including ethernet
> Or compared without tcp timestamp and 1500 to 4470.
> [EMAIL PROTECTED] ~]% echo "1460/(1+7+6+6+2+1500+4+12)*100"|bc -l
> 94.92847854356306892000
> [EMAIL PROTECTED] ~]% echo "4410/(1+7+6+6+2+4470+4+12)*100"|bc -l
> 97.82608695652173913000
Apparently 70-40 is too hard for me.
[EMAIL PROTECTED]
I did a rough, top-of-the-head, with ~60 bytes header (ETH, IP, TCP)
into 1500 and 4470 (a mistake, on my part, not to use 9216).
I still think the cost outweighs the gain, though there are some
reasonable arguments for the increase.
Gian Anthony Constantine
On Apr 12, 2007, at 12:07 PM,
On Thu, Apr 12, 2007 at 11:34:43AM -0400, [EMAIL PROTECTED] wrote:
>
>I think it's a great idea operationally, less work for the routers and more
>efficient use of bandwidth. It would also be useful to devise some way to
>at least partially reassemble fragmented frames at links capa
On 12-apr-2007, at 18:07, Saku Ytti wrote:
I agree. The throughput gains are small. You're talking about a
difference between a 4% header overhead versus a 1% header overhead
(for TCP).
6% including ethernet overhead and assuming the very common TCP
timestamp option.
Out of curiosity how
On Thursday 12 April 2007 06:14, Fernando André wrote:
> Citando Frank Bulk <[EMAIL PROTECTED]>:
> " but imagine how much work it
>
> > would save their abuse department in the long run"
>
> I think that Comcast trouble isn't has much has the company's affected I
> keep the idea that the best is t
On (2007-04-12 19:51 +0200), Iljitsch van Beijnum wrote:
> 8 bytes preamble
> 14 bytes ethernet II header
> 20 bytes IP header
> 20 bytes TCP header
> 12 bytes timestamp option
> 4 bytes FCS/CRC
> 12 bytes equivalent inter frame gap
>
> 90 bytes total overhead, 52 deducted from the ethernet pay
Large MTUs enable significant throughput performance enhancements for
large data transfers over long round-trip times (RTTs.) The original
question had to do with local subnet to local subnet where the difference
would not be noticable. But for users transferring large data sets over
long dista
> A few years ago, the IETF was considering various jumbogram options.
> As best I recall, that was the official response from the relevant
> IEEE folks: "no". They're concerned with backward compatibility.
worse. they felt that the ether checksum is good at 1500 and not
so good at 4k etc. they
> Last I heard, the IEEE won't go along, and they're the ones who
> standardize 802.3.
>
> A few years ago, the IETF was considering various jumbogram options.
> As best I recall, that was the official response from the relevant
> IEEE folks: "no". They're concerned with backward compatibility.
>> A few years ago, the IETF was considering various jumbogram options.
>> As best I recall, that was the official response from the relevant
>> IEEE folks: "no". They're concerned with backward compatibility.
>
> As I remember it, the IEEE did not say "no"
i was in the middle of this one. th
On 12-apr-2007, at 20:15, Randy Bush wrote:
A few years ago, the IETF was considering various jumbogram options.
As best I recall, that was the official response from the relevant
IEEE folks: "no". They're concerned with backward compatibility.
worse. they felt that the ether checksum is go
> It looks to me that the checksum issue is highly exaggerated or even
> completely wrong (as in the 1500 / 4k claim above). From
> http://www.aarnet.edu.au/engineering/networkdesign/mtu/size.html :
glad you have an opinion. take it to the ieee.
randy
mark does not have posting privs and has asked me to post the
following for him:
---
To: Gian Constantine <[EMAIL PROTECTED]>
From: Mark Allman <[EMAIL PROTECTED]>
cc: NANOG list <[EMAIL PROTECTED]>
Subject: Re: Thoughts on increasing MTUs on the internet
Date: Thu, 12 Apr 2007 11:47:35 -0400
Leigh:
How many customers do you serve that you have just 50 exceptions?
It's my understanding that the most efficient way to keep things clean for
cable modem subscribers is to educate subscribers to use port 587 with SMTP
AUTH for both the ISP's own servers and their customer's external mail
s
On Thu, 12 Apr 2007, Joe Loiacono wrote:
Large MTUs enable significant throughput performance enhancements for
large data transfers over long round-trip times (RTTs.) The original
This is solved by increasing TCP window size, it doesn't depend very much
on MTU.
Larger MTU is better for dev
[EMAIL PROTECTED] wrote on 04/12/2007 04:05:43 PM:
>
> On Thu, 12 Apr 2007, Joe Loiacono wrote:
>
> > Large MTUs enable significant throughput performance enhancements for
> > large data transfers over long round-trip times (RTTs.) The original
>
> This is solved by increasing TCP window size,
On Thu, 12 Apr 2007, Joe Loiacono wrote:
Window size is of course critical, but it turns out that MTU also impacts
rates (as much as 33%, see below):
MSS 0.7
Rate = - * ---
RTT(P)**0.5
MSS = Maximum Segment Size
RTT = Round Trip Time
P = packet loss
So am I
Hopefully I'll be forgiven for geeking out over DHCP on nanog-l twice
in the same week.
On Thu, Apr 12, 2007 at 11:20:18AM +0200, Iljitsch van Beijnum wrote:
> 1. It's no longer necessary to limit the subnet MTU to that of the
> least capable system
I dunno for that.
> 2. It's no longer necess
I believe the formula applies when the TCP window size is held constant
(and maybe as large as is necessary for the bandwidth-delay product).
Obviously P going to zero is a problem; there are practical limitations.
But bit error rate is usually not zero over long distances.
The formula is not
At 05:28 PM 4/12/2007, David W. Hankins wrote:
Hopefully I'll be forgiven for geeking out over DHCP on nanog-l twice
in the same week.
On Thu, Apr 12, 2007 at 11:20:18AM +0200, Iljitsch van Beijnum wrote:
> 1. It's no longer necessary to limit the subnet MTU to that of the
> least capable syst
On Thu, Apr 12, 2007 at 05:58:07PM -0400, Daniel Senie wrote:
> >> 2. It's no longer necessary to manage 1500 byte+ MTUs manually
> >
> >But for this, there has been (for a long time now) a DHCPv4 option
> >to give a client its MTU for the interface being configured (#26,
> >RFC2132).
>
> Trying t
At 06:09 PM 4/12/2007, David W. Hankins wrote:
On Thu, Apr 12, 2007 at 05:58:07PM -0400, Daniel Senie wrote:
> >> 2. It's no longer necessary to manage 1500 byte+ MTUs manually
> >
> >But for this, there has been (for a long time now) a DHCPv4 option
> >to give a client its MTU for the interfac
On Thu, Apr 12, 2007 at 06:18:56PM -0400, Daniel Senie wrote:
> Neither addresses interoperability on a multi-access medium where a
> new station could be introduced, and can result in the same MTU/MRU
> mismatch problems that were seen on token ring and FDDI.
Solving Ilijitsch's "#1" is a separ
Saku Ytti wrote:
> IXP peeps, why are you not offering high MTU VLAN option?
> From my point of view, this is biggest reason why we today
> generally don't have higher end-to-end MTU.
> I know that some IXPs do, eg. NetNOD but generally it's
> not offered even though many users would opt to use i
Iljitsch van Beijnum wrote:
Dear NANOGers,
It irks me that today, the effective MTU of the internet is 1500 bytes,
while more and more equipment can handle bigger packets.
What do you guys think about a mechanism that allows hosts and routers
on a subnet to automatically discover the MTU t
Steven M. Bellovin wrote:
On Thu, 12 Apr 2007 11:20:18 +0200
Iljitsch van Beijnum <[EMAIL PROTECTED]> wrote:
Dear NANOGers,
It irks me that today, the effective MTU of the internet is 1500
bytes, while more and more equipment can handle bigger packets.
What do you guys think about a mechanis
thanks ferg - and the local FBI concurs.
http://www.tech-404.com/calculator.html`
--bill
On (2007-04-13 00:17 +0100), Will Hargrave wrote:
> At LONAP a jumbo frames peering vlan is on the 'to investigate' list. I
> am not sure if there is that much interest though. Another vlan, another
> SVI, another peering session...
Why another? For neighbours that are willing to peer over eg.
On (2007-04-12 20:00 -0700), Stephen Satchell wrote:
> From a practical side, the cost of developing, qualifying, and selling
> new chipsets to handle jumbo packets would jack up the cost of inside
> equipment. What is the payback? How much money do you save going to
> jumbo packets?
It's
51 matches
Mail list logo