[e2e] A simple scenario. (Basically the reason for the sliding window thread ; -))

[Joe Touch]

David Borman wrote:
> Hi Joe,
> 
> 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.

That's in the margins of 'hyperoptimization' I noted above, IMO. I'm not
clear what the utility of having the larger MTU is there, vs., e.g.,
frame bursting, except that it offloads data coalescing to an outboard
processor. If that's the goal, then this amounts to an outboard 'network
coprocessor'.

>> 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 remote hosts.
> 
> 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 desire
>> for the first case where there are no alternatives., but only as a patch.
> 
> 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.

The above both look like outboard coprocessors. If that's the goal, then
you're really extending the boundary of what the endhost is, and that's
reasonable. Most other uses - to silently help someone who doesn't know
you're there - are the problem, IMO.

Joe


----------------------------------------
Joe Touch
Sr. Network Engineer, USAF TSAT Space Segment

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20070118/29745269/signature.bin