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

[Joe Touch]

This device offloads processing on behalf of the endpoint. Such devices
can offload on a per-socketbuffer basis; this isn't much different,
except that it sends IP packets to the offloader.

Buffering serves two purposes: help a source with an insufficient buffer
for the BW*delay product, and help compensate for a receiver that can't
keep pace with a bunch of little packets.

The former helps only if you have an endpoint that can send relatively
fast, but has poor buffering.

The latter helps only if you have a receiver that can't keep pace with
lots of small packets.

Both point to broken implementations, and trade correctness for
performance. That's not how the rest of TCP is optimized. IMO, this
argues for a different transport protocol, not for these splitters.

Joe

David Borman wrote:
> No, it's more than just Large Send Offload or Large Receive Offload. 
> That's done on a per-packet basis, without needing to keep much, if any
> state.  In the scenario I'm citing the splitter is also changing the
> window and the MSS option.  The remote host offers a (relatively) small
> window, the splitter offers a much bigger (512K) window to the host on
> the 64K MTU network (in addition to rewriting the MSS option).  With the
> small delay*bandwith to the remote host, the splitter has no trouble
> keeping the pipe full using standard ethernet packets.  But if those
> packets went all the way to the 64K host across the large
> delay*bandwidth 64KMTU network, there'd be a lot of idle time waiting
> for window updates, and you get much lower throughput from end-to-end.
>             -David Borman
> 
> On Jan 19, 2007, at 11:17 AM, Joe Touch wrote:
> 
>>
>>
>> rick jones wrote:
>>>> 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.
>>>
>>> Apart from calling it a splitter, superficially at least that resembles
>>> what some 10G NICs can do today, albeit with some explicit
>>> knowledge/assistance by the stack.  Large send has the stack(host)
>>> giving the NIC(splitter) a large "segment" which the NIC(splitter)
>>> resegments for the link.  Those flow across the ethernet to the other
>>> NIC(splitter) which if it has Large Receive Offload enabled will
>>> "upsegment" the ethernet-sized traffic and give larger segments to the
>>> receiving stack(host).
>>
>> Right - this looks like a cooperative outboard processor, which makes a
>> lot of sense in some environments when both the outboard processor and
>> host are managed/controlled by the same entity, but still makes very
>> little sense (to me) when that's not the case.
>>
>> Joe
>>
>> ------------------------------------------
>> Joe Touch
>> Sr. Network Engineer, USAF TSAT Space Segment
>>

-- 
----------------------------------------
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/20070121/7c89ae7d/signature.bin