> For example, I have seen where an HTTP proxy would receive 3 each 500 (or
> so) byte packets in and turn around an forward on a 1500 (or so) byte
> packet. An SPF can not do this as. An SPF can not do this as only end
> nodes can de-fragment. Also, this did not appear to be so much a
> defragmentation issue as it was a process of "store-review-forward" which
> created the de-fragmentation benefit.
>
> Greg
>
>
> ============================================================================
> Gregory Otto e-mail gdo @
newf .
com
Store and forward is the bane of the networking world. Let us compare the SPS
vs proxy approach:
[100 byte packets]
[SOURCE] 1ms/byte trans latency [PROXY] 1ms trans l. [DESTINATION]
1-100ms (out)
101-200ms (in)
101-200ms (out)
201-300ms (in)
201-300ms (out)
301-400ms (in)
(300 bytes sent)
401-700ms (out)
501-800ms (in)
(300 bytes received)
[100 byte packets]
[SOURCE] 1ms/byte trans latency [SPF] 1ms trans l. [DESTINATION]
1-100ms (out)
101-200ms (in)
101-200ms (out)
201-300ms (out)
201-300ms (in)
201-300ms (out)
301-400ms (out) 301-400ms (in)
301-400ms (in)
(300 bytes sent)
401-500ms (out) 401-500ms (in)
501-600ms (in)
(300 bytes received)
As you can see, the SPF thrashes the proxy resoundly, its destination
being able to process the first 100 bytes at 400ms, while the
proxy's sits on its hands till 800ms. The SPF destination is able
to process the last 100 bytes at 600ms - a full 200 ms (or better,
depending on processing latecy in the destination for the first
200 bytes) before the proxy network.
--
Prof. Julian Assange |If you want to build a ship, don't drum up people
|together to collect wood and don't assign them tasks
proff @
iq .
org |and work, but rather teach them to long for the endless
proff @
gnu .
ai .
mit .
edu |immensity of the sea. -- Antoine de Saint Exupery
Follow-Ups:
References:
|
|
