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

David Borman david.borman at windriver.com
Mon Jan 22 08:02:26 PST 2007


You keep missing the point.  The delay*bandwidth between the end  
hosts is sufficiently large that it can not be driven at full speed  
from end-to-end given the window advertised by the host on the  
ethernet side of things.  Even if that host advertised a sufficiently  
large window, the inefficiencies of small packets on the 64K MTU side  
of the network will keep the network from being driven at full speed,  
not to mention the cost of ramping up slowstart using 1.5K byte  
packets vs. 64K byte packets.

The splitter in this case is sitting between the two networks,  
transparently connecting what it has effectively turned into two TCP  
connections, providing the necessary resources to allow TCP to run  
optimally on each half of the path, without the end nodes needing to  
have explicit knowledge of the splitter.

TCP does not always work well in all scenarios, but there is a lot of  
value in being able to use TCP instead of designing a new transport  
and internet layer.  In a scenario like this, the splitter allows TCP  
to be used in an environment where it otherwise wouldn't work very well.

And sure, it'd be best if the splitter wasn't needed, and the  
connection could be run at full speed from end-to-end, but sometimes  
you have to deal with realities and not just theory.  Focusing on  
details and calling the implementation broken, and then ignoring the  
underlying issues, doesn't resolve anything.

			-David Borman

On Jan 21, 2007, at 12:01 PM, Joe Touch wrote:

> 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

More information about the end2end-interest mailing list