Development issues regarding the cerowrt test router project
 help / color / mirror / Atom feed
From: Robert Bradley <robert.bradley1@gmail.com>
To: cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] Baby jumbo frames support?
Date: Thu, 21 Jun 2012 18:03:37 +0100	[thread overview]
Message-ID: <4FE353E9.1020306@gmail.com> (raw)
In-Reply-To: <1340288726.671712236@apps.rackspace.com>

On 21/06/12 15:25, dpreed@reed.com wrote:
> I understand Dave Taht's long lecture - actually understood it years ago.  But frame aggregation is not the same thing as jumbo frames in a multi-technology Ethernet LAN.   Jumbo frames provide a way to exploit *end-to-end* frame sizes greater than 1500 bytes.  That means the source and destination TCPs get frames that are "whole" (and not random subassemblies of frames that may arrive close together in time).
>   

Your post makes more sense as a reply to Dave's post rather than mine, I 
think...

Just in case replying to mine was deliberate, though:

Going back to Alexander's original post, "baby" jumbo packets are quite 
simply a hack to get around the issues of PPPoE and reduced MTU.  For UK 
ADSL customers without loop-unbundling, most of the infrastructure 
between customer and ISP is owned/managed by one provider (BT 
Wholesale), and either PPPoA or PPPoE may be used on this link 
(http://blog.farnz.org.uk/2010/02/on-pppoa-pppoe-atm-and-adsl.html).  On 
the newer network, PPPoE is apparently(?) preferred.  (I am sure that 
there are others reading this that know far more about BT's ADSL setup 
than I do; if any of this is wrong, feel free to correct me here!)

Now, one of the issues of tunnelling is that you have overheads; in this 
case, the PPPoE header is 8 octets, with 1492 octets remaining for the 
tunnelled packet.  In theory, you could simply set the tunnel MTU to 
1492 bytes and have done with it - after all, you can always use path 
MTU discovery!  The problem is that PMTU black holes can and do exist, 
so that is not a viable option.  Ideally, you want your link to be 
1500-byte-safe instead.  One way to achieve this is to increase the 
frame size by just enough to contain a full 1500-octet packet within a 
PPPoE frame (8 octets larger in this case).  Your standard 1500-byte 
packet now becomes a 1508-byte PPPoE packet (8 bytes PPPoE header, and 
1500 bytes of content), which is sent from your router over the BT 
Wholesale network to your ISP's PPPoE server.  The server then extracts 
the embedded Ethernet frame and sticks it on to the ISP's network, with 
no reassembly required.

-- 
Robert Bradley

      reply	other threads:[~2012-06-21 17:03 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-16  9:53 Alexander Hulse
2012-06-16 12:54 ` dpreed
2012-06-21  0:50   ` Dave Taht
2012-06-21  0:58 ` Dave Taht
2012-06-21 13:33   ` Robert Bradley
2012-06-21 14:25     ` dpreed
2012-06-21 17:03       ` Robert Bradley [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FE353E9.1020306@gmail.com \
    --to=robert.bradley1@gmail.com \
    --cc=cerowrt-devel@lists.bufferbloat.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox