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

[David Borman]

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

>
>
> David Borman wrote:
>>
>> On Jan 22, 2007, at 4:05 PM, Joe Touch wrote:
> ...
>>>> 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.
>
> In that case you're making a case for an outboard ethernet adapter,
> e.g., like the USB dongles.

If you can't bring in ethernet, you aren't going to have USB...

>
>> 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.
>
> That's the part that's confusing. In order to warrant the splitter,  
> the
> ethernet side must keep up. But then you're saying here that the
> ethernet is slower.
>
> Either:
> ethernet keeps up
> 	which you need to assume to warrant a splitter,
> 	but which begs the question of why you have less capable
> 	net to the right
>
> ethernet doesn't keep up
> 	in which case aggregation doesn't help

Why is this not clear?  The overall capacity of the 64K network  
exceeds the capacity of the ethernet network.  So for large packets,  
the 64K network is better than the ethernet network.  But with the  
smaller ethernet sized packets, the 64K network is unable to make use  
of that capacity.  That's the scenario.


>
>> 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.
>
> In the latter case, you're not keeping up on the source-splitter side.
> Which means you don't need the splitter either to aggregate or to  
> buffer.

Huh?  I'm saying that even if you could replace the 64K network with  
an ethernet network, you'd improve the end-to-end performance from  
hosts on that network to remote hosts without the need for the  
splitter, but the cost of doing that is lower performance between  
hosts that used to be on 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.
>
> It's still very unclear what effects this is mitigating.

I'm sorry that you don't understand it.  I've tried to be clear in my  
description of the scenario.

The throughput across the 64K network with 1500 byte packets is worse  
than ethernet.  The throughput across the 64K network with larger  
packets exceeds the throughput over ethernet.  And even without that  
issue, the typical window at the remote host across ethernet is not  
large enough for the delay*bandwidth end-to-end.  That's the  
scenario.  The splitter mitigates those issues without needing to add  
a new transport.

			-David Borman