Re: [Linux-ATM-General] Supporting tcpdump, pseudo interfaces, and DSL MTU's

[MIke W. <we...@cs...>]

I'm not really sure what the question is here.  But here are few ideas.

(1) 1500 byte NPDUs don't impose an "unreasonable" level of link level 
overhead.
If you include MAC header,  CRC,  Prefix its only 44/1544 (as I 
recall).  Anyway
its way less than ATMs 11% cell header penalty.
(2) 1500 bytes DO hurt you in a BIG WAY  at GBit+ speeds because of the 
overhead
of processing them.  At 1 Gbps they arrive or need to be sent every 12 
usec or so.

But at current DSL speeds there is truly no significant PERFORMANCE benefit
for using Phat Phrames AT THE ENDPOINT.

I wrote a paper on the impact of fat frames and interrupt
coalescing a few years ago.  If you are interested, I can send it at you.

I have a couple of (albeit 2+ year old)  Linksys routers  and  while Cisco's
high end products  support  the "jumbo frame (9K  quasi standard)" these
don't.

Regards,
Mike Westall
Professor of Computer Science
School of Computing
Clemson University


Philip Prindeville wrote:
>   I was writing some new startup scripts for an embedded box that supports DSL, and it occurred to me that I didn't know what the optimal DSL (PPPoE or PPPoA) MTU's should be.
>
> You can make the argument that the end-systems sitting behind a router/firewall *might* be connected by 10mb/s Ethernet II over coax and/or a dumb hub, hence 1500 byte MTU makes sense.  But frankly this is highly unlikely.
>
> Everyone is using twisted pair, switches, and 100M, 1G, or 10G hardware these days... and the 1500 byte limit seems completely arbitrary since "jumbogram" support is more the rule than the exception (I remember when I was at Cisco 5 years ago, we did regression suites to make sure that all 100M interfaces could indeed support jumbograms of at least 4096 bytes, at least on routers running IOS).
>
> So given that, you'd think that the prevailing logic would be that all *transit links* (including the DSL hop from the C.O. to the subscriber) should be able to support *at least* the MTU that the end-user might send, yet I keep seeing numbers like 1478 or smaller crop up.
>
> All of the "fat pipe" connectivity within the ISP/IXC is going to be able to support jumbograms... so why should the DSL hop to the end-user ever be smaller than 1500 bytes?  What would be the point?  And indeed, do most DSL providers support larger MTU's?
>
> Which, wanting to investigate this, brought me to the fact that (a) I couldn't run tcpdump on an ATM (DSL) interface and look at the actual MAC stream, and (b) while PPPoE creates a pseudo-interface (nas0) via br2648ctl, using the popular pppoatm.so kernel plugin doesn't create a similar pseudo-interface.  Should the pppox kernel module create a pseudo-interface that supports hooks for tcpdump inspection?  I'm thinking it should.
>
> Anyone else have an opinion?
>
> Thanks,
>
> -Philip
>
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> Linux-atm-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-atm-general
>
>
>