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

Joe Touch touch at ISI.EDU
Mon Jan 22 14:49:48 PST 2007



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.

> 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

> 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.

>> 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.
-- 
----------------------------------------
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/20070122/d1f75b85/signature.bin


More information about the end2end-interest mailing list