[e2e] Satellite networks latency and data corruption

[Scott,Keith L.]

A few comments:

1.  A common claim is that if the proxies are proximate to the satellite
channel, then one can assume that loss between the proxies is due to
corruption and not congestion.  This requires a number of assumptions,
including that the proxies are smart enough to NOT over-drive the
satellite link.  However, this knowledge can sometimes be useful, see 2b
below.

2.  While it's true that proxies don't shorten the RTT from the point of
view of the application, they do shorten the RTT as seen by TCP.  Thus
end systems can use standard window sizes and not have to allocate a ton
of buffer space to all connections, whether they go over the satellite
or not.  Automatic buffer tuning mitigates this.

2b. Perhaps more importantly though, proxies allow the parameters of the
TCP connection (window size, congestion control algorithm and settings,
etc.) to change to accommodate the _local_ network characteristics.
This can give dramatically better performance, depending on the
applications involved.  FTP performance can be substantially improved;
stop-and-wait application protocols (e.g. CIFS) will still take a hit
from the long (e2e) RTT.

3. The only point I would make here is that if one opens up the default
window sizes for all endpoints to get good performance 'just in case'
connections go over large BDP channels, it may end up consuming memory
for small BDP connections as well.


On your last point, consider a point in the P2--RCV network where
multiple flows, some of them over the satellite and some of them short
RTT, share a link.  If there is congestion loss on that link, the
long-RTT flow will be 'unfairly' penalized in the recovery process, and
the short-RTT flows will get more of the link bandwidth.  In the proxy
environment, the P2--RCV flows that go over the satellite are
'short-RTT' on the P2--RCV part of the path, and so compete on a more
even basis with other flows.

		--keith

>-----Original Message-----
>From: end2end-interest-bounces at postel.org 
>[mailto:end2end-interest-bounces at postel.org] On Behalf Of Detlef Bosau
>Sent: Sunday, July 17, 2005 8:00 AM
>To: end2end-interest at postel.org
>Subject: Re: [e2e] Satellite networks latency and data corruption
>
>Christian Huitema wrote:
>> 
>> Bottom line, you need to actually measure the system for 
>which you are designing the protocol. There is no "one size 
>fits all" answer to your question.
>> 
>> > Now, the authors propose a splitting/spoofing architecture:
>> >
>> > SND----netw.cloud----P1---satellite 
>link----P2-----netw.cloud----RCV
>> >
>> > P1, P2: "Proxies".
>> 
>> In theory, there is no particular performance benefit to the 
>proxy architecture. If the transmission protocol uses 
>selective retransmission and large windows, the differences of 
>performance between SND-RCV and P1-P2 are truly minimal. In 
>practice, there is only an advantage if the end-to-end 
>implementations are not well tuned, e.g. do not allow for 
>large windows.
>> 
>
>The authors of the aformentioned papers claim three problems.
>
>1.: Packet loss rate / loss differentiation.
>2.: Long RTT.
>3.: Restrictions of window size.
>
>My remarks on these:
>Now, for 3: The authors don´t mention / discuss window scaling.
>For 2: A proxy on transport layer cannot shorten the RTT as 
>perceived by
>the _application_.
>For 1: I´m not quite sure, whether loss differentiation is really a
>problem here. From what you say I conclude that this is a borderline
>case.
>
>However, conerning long RTT in combination with window size, there may
>be a problem left. It may occur that a flow´s fair share of capacity
>along the satellite link becomes quite large (this is of course load
>dependent). Is it possible, that it takes an unwanted number 
>of "rounds"
>then for a sender to 
>achieve the appropriate congestion window? I´m not quite sure about
>this, because proper window scaling should alleviate this problem.
>
>Detlef Bosau
>
>
>
>-- 
>Detlef Bosau
>Galileistrasse 30
>70565 Stuttgart
>Mail: detlef.bosau at web.de
>Web: http://www.detlef-bosau.de
>Mobile: +49 172 681 9937
>