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 all the
consumers that do use alternate
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 all
the
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 and
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 prevent
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?
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 subnet
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 them,
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
* [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
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 hosts
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
* 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 is
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
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 backward
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
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: no. They're
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
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 overhead
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 capable
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 to rate
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 payload, 38
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
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.
As I
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. they said no.
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
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
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
[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, it
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
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
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 to do this
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 interface being
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 separate
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 it.
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
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 mechanism
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
