[e2e] Satellite networks latency and data corruption

[Detlef Bosau]

"Scott,Keith L." wrote:
> 
> 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.
> 

That´s the reason why I asked for error rate estimates. When I refer to
Christian Huitema´s post, I´m not quite sure whether we need proxies
around the satellite link or wheter FEC will suffice. It´s, however, a
question. Besides the posts by Christian Hutima, Adrian Hooke just sent
me some references for helpful material here.

The central question here is indead, whether proxies really make sense.
If so, of course a number of questions arise as you point out in 2b.
Particularly, I would expect that the use of _rate_ controled protocols
on the satellite link would be advantegous over window based protocols,
because in window based protocols it takes a number of "rounds",
therefore a large time, to achieve equilibrium.

One could investigate architechtures which couple window based TCP
segments with rate controled ones and ask for possible problems and
their solutions. However, before I would dive into the goary details
here, I want to avoid mounting a dead horse.
And at least from Christian´s posts I learned: the horse could have more
vitality....


> 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

This is clear. This is the rationale behind a proxy to shorten the RTT
on transport layer, to hide a large LBP etc.

However, I often intendedly take a user´s perspective. The central
question is: What is the benefit to the user, if we introduce a proxy? I
think, any research must never ignore this question. If a proxy shortens
the RTT on transport layer and there is no benefit to the user, that
would be maximum effort with minimum effect. And if satellite links
won´t be used for interactive applications, due to the large RTT, but
only for long term flows, I really wouldn´t care about
fife or ten rounds (i.e. 2.5 or 5 seconds) for a flow to achieve
equilibrium, if the subsequent "download of the new RedHat ISO" lasts
two hours anyway.

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

Should we distinguish between LTN and LFN here? LTN: An internet
backbone, where a flows fair share of capacity is some few packets. The
network is "thin".
LFN: A user connected to the Internet via a satellite phone. In that
case, the fair share of capacity may indeed become quite large. The
network is "fat".

In case of "LTN" (from a users point of view) I´m not totally convinced
that the situation is that much different from intercontinental
terrestrical deep sea cable links.

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


Hm. Is this behaviour really _that_ terrible?

It´s only a question.

But to the best of my knowledge, the vast majority of TCP flows are
short term flows (less then 20 packets in about 95 % of flows). These
are often interactive dialogs where a user requests quick responses from
the system. However, if satellite links are used for long term flows
(e.g. large file transfers) who cares for some unfairness which causes a
long term flow to last 10 percent longer? Or 20 percent?

I don´t know. However, it´s a question of relevance, and therefore the
question for "the horse".

And I even heared about the opinion: Anyone is interested in bulk
transfers, perhaps we can ignore some short term flows.

My opinion on this one is: The Internet is made for the users and not
vice versa. And when a bulk transfer lasts one hour and five minutes
instead
of one hour, hardly anyone would really mind. However, when a WWW
server´s response time increases from ten seconds to eleven..... 
Have you ever worked at a user´s help desk? I have.......

A purely academic view will be of course quite different from that. At
least, because long term flows are much easier to deal with  ;-)
But again: research must not ignore reality and user´s requirements. So,
I see bulk transfers as a simplification. The really interesting thing
is user interaction and responsiveness because that defines the "look
and feel" of the Internet and therefore its acceptance by the users.

Consequently, it may be worthwile to (re)mount the diffserve horse here:
e-mail is not the same as WWW. A remote login via SSH is not the same
as a download of the latest RedHat ISOs. I can very well imagine to
treat different things in different ways. This may be more obvious 
in mobile wireless systems than in satellite links. Particularly in
mobile wireless networks you always immediately encounter tradeoffs when
you consider the use of PEP: large buffers vs. varying bandwidth,
optimum throughput vs. optimum responsiveness etc. Whereas diffserve may
be somewhat academic for the wirebound Internet, I can very well imagine
that it may become helpful in systems with any kind of PEP. (Eventually,
someone will use the TOS bits =8-))


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