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

[David Borman]

On Jan 22, 2007, at 4:05 PM, Joe Touch wrote:

>
>
> David Borman wrote:
>>> This is a contradiction: clearly the splitter needs to keep up with
>>> receiving small packets at rate or it can't sustain emitting the  
>>> large
>>> packets at full speed. If the splitter can do this, then the  
>>> destination
>>> can. The fact that it doesn't means this is (by definition) a  
>>> patch to a
>>> broken system.
>>
>> Ah, you are assuming that both the ethernet side and the 64K MTU  
>> side of
>> the path operate equally efficiently using small packets.
>
> source ---------------> splitter ----------------> dest
>            1500byte                64K byte
>
>
> You're claiming that the splitter is required to keep the 64Kbyte side
> running at full rate. That means the 1500-byte side has to handle
> packets roughly 40x faster. Otherwise, the 64K byte side is not  
> running
> at high-rate.
>
> So here's what we have:
> 	- dest can handle 64K but not 1500
> 	- source must handle 1500 at high rate
> 	- splitter must receive 1500 at high rate
>
> Now you're claiming that there's a link (source-splitter) that's
> efficient enough for small packets. If that's the case, why would we
> ever want the kind of link that's being used splitter-dest?

If all you're ever going to do is talk through the splitter to remote  
ethernet hosts, then yes, it'd be preferable to bring ethernet  
directly to the host instead of using the 64K MTU network.  But you  
don't always get what you want.  For various reasons it might not be  
possible to bring ethernet directly to the hosts on the 64K network.   
And while the 64K MTU network may not be as efficient with 1500 byte  
packets as an ethernet network, replacing it with an ethernet network  
might be slower internally than the 64K MTU network.  So the trade  
off is a faster 64K network that works well with large packets but  
not ethernet sized packets, vs. a slower ethernet network that works  
better with ethernet sized packets, but doesn't have the overall  
capacity of the 64K network.

>
> Again, this argues that something is seriously broken.

Sometimes there isn't an optimal solution and you have to make hard  
choices.  Just because it isn't the one you want doesn't mean things  
are *broken* when you then try to mitigate the effects of those choices.

			-David Borman