[e2e] A simple scenario. (Basically the reason for the sliding window thread ; -))
david.borman at windriver.com
Thu Jan 18 13:20:48 PST 2007
A little more detail, see below.
On Jan 18, 2007, at 12:00 PM, Joe Touch wrote:
> David Borman wrote:
>> There are real-world scenarios where the insertion of a splitter
>> into a
>> TCP path does make a lot of sense. The cases I am familiar with
>> all are
>> necessitated by a severe mismatch in MTU, buffering and performance,
> Taking each individually:
> Mismatched MTU - sounds like a PMTU issue, otherwise you're
> hyper-optimizing IP overheads in ways that the Internet protocols are
> not designed to support. If you have a broken PMTU situation, using a
> splitter to 'patch' the situation is fixing one broken system with
> another, IMO.
It's not a PMTU issue, PMTU finds the smallest MTU along the path.
I'm talking about a large MTU mismatch, such as a standard ethernet
on one side with 1500 byte packets, and an interface with a 64K MTU
on the other side (HIPPI, FibreChannel, etc). The goal is to be able
to use the large packets between the splitter and the host on the 64K
MTU network, an ethernet sized packets out to the other endpoint.
With PMTU and without the intervention of the splitter, packets will
be limited to 1500 bytes along the whole path.
> Buffing problems could as easily be solved by non-splitter PEPs that
> buffer and retransmit, acting like a two-port router. The same is true
> for many performance problems.
In this scenario, the 1500 byte host may be only offering a window
of, say 16K. The splitter offers a window to the 64K host of
something like 512K. This allows the 64K MTU host to send multiple
64K sized packets, which the splitter then sends out as ethernet size
packets to the remote host. In other words, for a 16K vs. 512K
scenario, for each window of data transferred between the 64K host
and the splitter, there are 32 windows of data transferred out to the
Conversely, as 1500 byte packets arrive from the remote host, they
are acked and accumulated into larger packets that are then
transferred over the 64K MTU network in larger packets.
> I don't agree that either makes sense, although I appreciate the
> for the first case where there are no alternatives., but only as a
Again, I don't think a splitter is a good general solution, but there
are specific cases where it can do what needs to be done within the
constraints of the system.
> Joe Touch
> Sr. Network Engineer, USAF TSAT Space Segment
More information about the end2end-interest