On Tue, 16 Dec 1997, Fred Baker wrote:

> At 7:22 PM -0500 12/16/97, cbonafie@... wrote:
> >I'd like to explore some of the pros and cons of leos and geos re
> >latency--find out where things stand in the IETF on best practices in
[snip]
>
> But it does so at a cost - instead of the nice stable geosynchronous orbit,
> you've now got the message bouncing from satellite to satellite (which are
> at random distances from each other, continuously changing), traversing
> something resembling an arc around the earth, but with a significantly
> wider radius. It's therefore not going to be as little time as the
> corresponding terrestrial link would be. And the amount of time will be
> continuously varying - sometimes in a steady drift (what we geeks call "low
> frequency jitter"), and sometimes in a jump, as the next hop in a
> satellite-satellite route jumps from one bird to another (what we geeks
> call "high frequency jitter"). This continuous variation in delay means
> that TCP's window duration measurement algorithms will be constantly
> rubber-banding - and snapping - and it means that there can be packet
> reordering in the air - well, in the vacuum above the air.

Can someone clarify how fast the 'route' is going to change in a TCP (or
other) connection when GEO inter-satellite routing is involved? It would
seem that satellites move across the sky relatively fast, but still will
spend at least a few minutes above the horizon when they are the next hop
for each machine. Doesn't this mean that the number of individual TCP
connections that are severely affected by this will be relatively small,
or is there something I'm missing here? I guess what I'm asking whether
a connection is going to be changing relatively slowly (ie over a few
hundred seconds) or very rapidly (over a couple of seconds).

So, will your TCP implementation need to be *that* robust for LEO when
compared to that for GEO?

Also, does anyone know who is writing the inter-satellite routing
protocols and how to get on some sort of mailing-list about them (I'm
relatively new to this mailing-list so please forgive me if this is old
hat...)?

Thanks,


Sam


>
> So each has an advantage. GEOS is stable, and (comparitively) inexpensively
> has a very wide reach. If your application - voice, video, IP Multicast
> services, etc. - is hurt by jitter or packet reordering, GEOS is your
> friend. If your TCP implementation is VERY robust, and jitter and
> reordering are not issues to your application, then LEOS will in fact give
> you lower end to end latency; it will require a constellation of 300
> satellites to do it, though.
>
> And if you're one of the remaining 90% of the world, my advice is, try it
> and use the one that works best for you. You might decide either way, and
> make that decision for good reasons.
>
> If you want my honest opinion, in so many words, this whole debate in the
> press about GEOS vs LEOS, and delay, is not a technical debate. It has
> technical aspects, but those who understand them look at them and say "OK,
> so do this thing defined in <mumble>, and you'll be fine." It's really a
> marketing debate, and insofar as the press goes beyond its educational role
> to leading folks to make simplistic "me tarzan, you jane, this good, that
> bad" analysis, it has misled its readership and become the tool of one side
> or the other.
>
> You don't want to be in that position, right?
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>  Opportunity doesn't knock anymore; now it emails
>
>
>


****************************************
Sam Critchley
International Systems Engineer
UUNET
samc@...
Tel: (+44) 1223 250444
****************************************

At 05:38 PM 12/16/97 -0800, Fred Baker wrote:

>... on the order of half a second of fixed propagation delay. TCP will
transfer
>data at one window per round trip, a round trip is on the order of half a
>second, and slow start makes GEOS look bad. All of this is true.
>
>There are some fixes. TCP "spoof" engines that terminate the TCP session on
>either side of the satellite link can be used to make the "round trip" in
>question only account for terrestrial time. This means that end to end
>security (IPSEC) and some end to end assumptions are violated - but heck,
>in a world full of NATs, that's not news. TCP Large Windows (implemented in
>Microsoft Window s '98, I am told) also helps for long-lived sessions, and
>with HTTP 1.1 and 2.0, sessions are growing in length. So TCP does in fact
>work over GEOS, and the latency issues can be mitigated somewhat. Fifteen
>years of experience in the Internet says it works just fine, there's just
>some considerations you need to make.

... good writing, Fred.  Can I add my $0.02?

In the "real-world" of satellites I've lived in for the past decade or
more, I've seen a lot of marginal links, due to any number of
considerations and variables which can degenerate C/N and Eb/No
performance, and which therefore raise BER to levels which can easily allow
for the corruption of data.  With Eudora's latest offering on the 'net up
to some 9mb in size, a BER of 10E-6 would be pretty useless.  "Spoofing"
would pass the file to a user without noticing the lost data, and my end
user would quickly conclude that "my" Internet sucks.  and, the user would
be correct.  :-)

>Now, let's talk about LEOS.
>If you want my honest opinion, in so many words, this whole debate in the
>press about GEOS vs LEOS, and delay, is not a technical debate. It has
>technical aspects, but those who understand them look at them and say "OK,
>so do this thing defined in <mumble>, and you'll be fine." It's really a
>marketing debate, and insofar as the press goes beyond its educational role
>to leading folks to make simplistic "me tarzan, you jane, this good, that
>bad" analysis, it has misled its readership and become the tool of one side
>or the other.

I agree.

I also think a most important distinction between the two services will be
billing methods.  LEOS plan to bill by increment of time, or by the number
of bits passed, or some other incremental-use system.  GEOS have
traditionally offered fixed costs based on power and bandwidth, though this
may change based on some of the conversations I've heard at recent
conferences.  (I don't really think it will, due to competitive pressures.)
  A fixed cost plan works for the 'net - for ISP businesses, providers,
etc., who can't really function well if they don't know their own costs.
Incremental billing will work for "direct-to-end-user" services far better
than to intermediate ISPs.  Different customers, different applications
therefore seem better served by the two platforms.

Frankly, as the owner of a couple of ISP businesses with thousands of
end-users (translation: morons), I'd rather not deal with the end-users in
160 countries - the support issues will bankrupt you if you're not careful.

B

It seems difficult to believe that the designers of LEO systems will not try to
minimize delay variation
on their links (by using buffers for e.g.). It would be difficult to provide
even basic telephony services
if the link delay could vary by large amounts. Sure would be nice to get some
input from the folks at
Iridium, Teledesic, or Celestri
Ashok Rao
Senior Scientist
Network Technology
COMSAT Labs

fred@... wrote :

> cbonafie@... wrote:
>>I'd like to explore some of the pros and cons of leos and geos re
>>latency--find out where things stand in the IETF on best practices in
>>this area, where the satellite people would like to take the issue, if
>>they're trying to go further than refining the state of the
>>specifications, and what kinds of changes are being made and might need
>>to be made in infrastructure equipment (like routers) to better
>>accomodate bandwidth from the sky.

>But it does so at a cost - instead of the nice stable geosynchronous orbit,
>you've now got the message bouncing from satellite to satellite (which are
>at random distances from each other, continuously changing), traversing
>something resembling an arc around the earth, but with a significantly
>wider radius. It's therefore not going to be as little time as the
>corresponding terrestrial link would be. And the amount of time will be
>continuously varying - sometimes in a steady drift (what we geeks call "low
>frequency jitter"), and sometimes in a jump, as the next hop in a
>satellite-satellite route jumps from one bird to another (what we geeks
>call "high frequency jitter"). This continuous variation in delay means
>that TCP's window duration measurement algorithms will be constantly
>rubber-banding - and snapping - and it means that there can be packet
>reordering in the air - well, in the vacuum above the air.

In addition, I understand that some LEO systems could involve additional
delay due to on-board processing and switching between satellites.  I have
not seen reliable estimates of this delay but I understand that it could be
significant taking into consideration that a typical message may need to
pass through several LEO satellites, each contributing some processing
delay.

If anyone has definitive knowledge in this area I would appreciate it.
Thanks.

>So each has an advantage..... (text deleted) And if you're one of the
remaining >90% of the world, my advice is, try it and use the one that works
best for you. >You might decide either way, and make that decision for good
reasons.

I fully concur.


************************************************
Hany K. Eldeib, Ph.D.
Principal Engineer, Advanced Programs & Systems
INTELSAT
Washington, D.C., USA
Phone: 202-944-6949
Fax:      202-944-8211
Internet:  hany.eldeib@...
INTELSAT on WWW:  http://www.intelsat.int
************************************************
-------------
Original Text
From FRED@SMTPGATE (Fred Baker) {fred@...}, on 16/12/97 8:38 PM:
To: CBONAFIE@SMTPGATE {cbonafie@...}
Cc: MASCHRAD@SMTPGATE {maschrad@...}, TCP-OVER@SMTPGATE
(tcp-over-satellite) {tcp-over-satellite@...}

At 7:22 PM -0500 12/16/97, cbonafie@... wrote:
>I'd like to explore some of the pros and cons of leos and geos re
>latency--find out where things stand in the IETF on best practices in
>this area, where the satellite people would like to take the issue, if
>they're trying to go further than refining the state of the
>specifications, and what kinds of changes are being made and might need
>to be made in infrastructure equipment (like routers) to better
>accomodate bandwidth from the sky.

I think you'll find that the situation isn't as clear cut as either side of
that debate would like to make it sound. Like many things in engineering,
there are trade-offs, and things work differently depending on how you
trade them off.

First, let's talk about GEOS. GeoSynchonous Orbit satellites are 22,600
miles up in the sky. Multiply by the speed of light, and you get something
on the order of 1/8 of a second. So a message which is sent via a
geosynchronous satellite takes 1/8 second to go to the bird, and 1/8 of a
second to come back down - in addition to whatever time the message itself
would take at whatever speed you sent it (bits in message divided by bits
per second). Oh, you wanted an acknowledge? That's two messages, something
on the order of half a second of fixed propagation delay. TCP will transfer
data at one window per round trip, a round trip is on the order of half a
second, and slow start makes GEOS look bad. All of this is true.

There are some fixes. TCP "spoof" engines that terminate the TCP session on
either side of the satellite link can be used to make the "round trip" in
question only account for terrestrial time. This means that end to end
security (IPSEC) and some end to end assumptions are violated - but heck,
in a world full of NATs, that's not news. TCP Large Windows (implemented in
Microsoft Window s '98, I am told) also helps for long-lived sessions, and
with HTTP 1.1 and 2.0, sessions are growing in length. So TCP does in fact
work over GEOS, and the latency issues can be mitigated somewhat. Fifteen
years of experience in the Internet says it works just fine, there's just
some considerations you need to make.

Now, let's talk about LEOS. Low Earth Orbit means just that - on the order
of a few hundred to 1000 miles up. Multiply by the speed of light, and you
get some amount of time, but not all that much compared to 22,600 miles. So
you do the same calculation, and the base TCP session will indeed go more
rapidly at one window per round trip. This is good, and I don't think
you'll find anyone that says it's not true.

But it does so at a cost - instead of the nice stable geosynchronous orbit,
you've now got the message bouncing from satellite to satellite (which are
at random distances from each other, continuously changing), traversing
something resembling an arc around the earth, but with a significantly
wider radius. It's therefore not going to be as little time as the
corresponding terrestrial link would be. And the amount of time will be
continuously varying - sometimes in a steady drift (what we geeks call "low
frequency jitter"), and sometimes in a jump, as the next hop in a
satellite-satellite route jumps from one bird to another (what we geeks
call "high frequency jitter"). This continuous variation in delay means
that TCP's window duration measurement algorithms will be constantly
rubber-banding - and snapping - and it means that there can be packet
reordering in the air - well, in the vacuum above the air.

So each has an advantage. GEOS is stable, and (comparitively) inexpensively
has a very wide reach. If your application - voice, video, IP Multicast
services, etc. - is hurt by jitter or packet reordering, GEOS is your
friend. If your TCP implementation is VERY robust, and jitter and
reordering are not issues to your application, then LEOS will in fact give
you lower end to end latency; it will require a constellation of 300
satellites to do it, though.

And if you're one of the remaining 90% of the world, my advice is, try it
and use the one that works best for you. You might decide either way, and
make that decision for good reasons.

If you want my honest opinion, in so many words, this whole debate in the
press about GEOS vs LEOS, and delay, is not a technical debate. It has
technical aspects, but those who understand them look at them and say "OK,
so do this thing defined in <mumble>, and you'll be fine." It's really a
marketing debate, and insofar as the press goes beyond its educational role
to leading folks to make simplistic "me tarzan, you jane, this good, that
bad" analysis, it has misled its readership and become the tool of one side
or the other.

You don't want to be in that position, right?

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
	 Opportunity doesn't knock anymore; now it emails

At 8:38 PM -0500 12/16/97, Fred Baker wrote:


>
>First, let's talk about GEOS. GeoSynchonous Orbit satellites are 22,600
>miles up in the sky. Multiply [sic] by the speed of light, and you get
>something
>on the order of 1/8 of a second....
>
>Now, let's talk about LEOS. Low Earth Orbit means just that - on the order
>of a few hundred to 1000 miles up. Multiply [sic] by the speed of light,
>and you
>get some amount of time, but not all that much compared to 22,600 miles.

Nice write up, Fred.

Nits: dividing by the speed of light works better than multiplying.

And, I _think_ (the flesh sags, the hair falls out, the memory fails...)
that the geosynchronous orbit is 22,300 miles.  But who's counting?

Key thing is that we're going to see many more satellite transport options
over the next 3-5 years.  And, there will surely be selected situations for
which one or more SATCOM alternatives will solve problems that purely
terrestrial means won't be able to solve.  Stay tuned.  YMMV.

--Steve G.

Hi~
I have several Questions in Satellite network.

1. Error modeling in satellite.
     I tring simulation in NS for Satellite Link. Some paper choice
different error modeling.
     What is similar at actual satellite link?
    (Could i get it?)

2. Using FEC, we can get more improving BER.
    For BER = 10^-6, 10^-7.. How much overhead need?

Thanks.

At 7:22 PM -0500 12/16/97, cbonafie@... wrote:
>I'd like to explore some of the pros and cons of leos and geos re
>latency--find out where things stand in the IETF on best practices in
>this area, where the satellite people would like to take the issue, if
>they're trying to go further than refining the state of the
>specifications, and what kinds of changes are being made and might need
>to be made in infrastructure equipment (like routers) to better
>accomodate bandwidth from the sky.

I think you'll find that the situation isn't as clear cut as either side of
that debate would like to make it sound. Like many things in engineering,
there are trade-offs, and things work differently depending on how you
trade them off.

First, let's talk about GEOS. GeoSynchonous Orbit satellites are 22,600
miles up in the sky. Multiply by the speed of light, and you get something
on the order of 1/8 of a second. So a message which is sent via a
geosynchronous satellite takes 1/8 second to go to the bird, and 1/8 of a
second to come back down - in addition to whatever time the message itself
would take at whatever speed you sent it (bits in message divided by bits
per second). Oh, you wanted an acknowledge? That's two messages, something
on the order of half a second of fixed propagation delay. TCP will transfer
data at one window per round trip, a round trip is on the order of half a
second, and slow start makes GEOS look bad. All of this is true.

There are some fixes. TCP "spoof" engines that terminate the TCP session on
either side of the satellite link can be used to make the "round trip" in
question only account for terrestrial time. This means that end to end
security (IPSEC) and some end to end assumptions are violated - but heck,
in a world full of NATs, that's not news. TCP Large Windows (implemented in
Microsoft Window s '98, I am told) also helps for long-lived sessions, and
with HTTP 1.1 and 2.0, sessions are growing in length. So TCP does in fact
work over GEOS, and the latency issues can be mitigated somewhat. Fifteen
years of experience in the Internet says it works just fine, there's just
some considerations you need to make.

Now, let's talk about LEOS. Low Earth Orbit means just that - on the order
of a few hundred to 1000 miles up. Multiply by the speed of light, and you
get some amount of time, but not all that much compared to 22,600 miles. So
you do the same calculation, and the base TCP session will indeed go more
rapidly at one window per round trip. This is good, and I don't think
you'll find anyone that says it's not true.

But it does so at a cost - instead of the nice stable geosynchronous orbit,
you've now got the message bouncing from satellite to satellite (which are
at random distances from each other, continuously changing), traversing
something resembling an arc around the earth, but with a significantly
wider radius. It's therefore not going to be as little time as the
corresponding terrestrial link would be. And the amount of time will be
continuously varying - sometimes in a steady drift (what we geeks call "low
frequency jitter"), and sometimes in a jump, as the next hop in a
satellite-satellite route jumps from one bird to another (what we geeks
call "high frequency jitter"). This continuous variation in delay means
that TCP's window duration measurement algorithms will be constantly
rubber-banding - and snapping - and it means that there can be packet
reordering in the air - well, in the vacuum above the air.

So each has an advantage. GEOS is stable, and (comparitively) inexpensively
has a very wide reach. If your application - voice, video, IP Multicast
services, etc. - is hurt by jitter or packet reordering, GEOS is your
friend. If your TCP implementation is VERY robust, and jitter and
reordering are not issues to your application, then LEOS will in fact give
you lower end to end latency; it will require a constellation of 300
satellites to do it, though.

And if you're one of the remaining 90% of the world, my advice is, try it
and use the one that works best for you. You might decide either way, and
make that decision for good reasons.

If you want my honest opinion, in so many words, this whole debate in the
press about GEOS vs LEOS, and delay, is not a technical debate. It has
technical aspects, but those who understand them look at them and say "OK,
so do this thing defined in <mumble>, and you'll be fine." It's really a
marketing debate, and insofar as the press goes beyond its educational role
to leading folks to make simplistic "me tarzan, you jane, this good, that
bad" analysis, it has misled its readership and become the tool of one side
or the other.

You don't want to be in that position, right?

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
	 Opportunity doesn't knock anymore; now it emails

At 1:13 PM -0800 12/16/97, Aaron Falk wrote:
>Check out  http://techweb.cmp.com/nc/803/803hrb.html

Turns out the drafts it mentions I was going to write are being worked on
by Sally Floyd instead.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
	 Opportunity doesn't knock anymore; now it emails

Check out  http://techweb.cmp.com/nc/803/803hrb.html

aaron


--
Aaron Falk    (310) 814-4932
TRW, Inc
Electronics Systems & Technology Division
Aaron.Falk@...

> At 14:47 -0500 12/12/97, Jim Mercer wrote:
> >we currently have a 2mbit circuit which due to the issues being discussed
> >here,
> >is highly under utilized.
> >
> >as such, i am looking for solutions which will help me maximize the
> >utilization
> >until such point that the solutions discussed here are forwarded and
> >implemented.
>
> Could you give us more detail on the nature of the traffic flowing over
> this link.  In particular, I am interested in the number of users that
> simultaneously access the circuit, and whether the traffic is mainly bulk
> data transfer or mainly interactive or near-interactive?

at this point in time, there are a few clusters of pc's connected via G.703
links to the central facility, which then uses the 2mbit (also G.703) satelite
link to connect to our internet connected routers.

the link has only been operational for 2 weeks (actually quite a feat
considering we only ordered the circuit from the satelite provider 5 weeks ago).

we expect the usage to grow fairly quickly.

the nature of the link will be that of a traditional ISP.

we expect to have a number of terminal servers, as well as the campuses of a
few universities and offices of businesses to be attached in the near future.

much of the traffic will be web browsing which i guess is sorta like saying
interactive bulk transfer.  8^)

in addition to the web browsing, i would think that things like streaming
audio and video would be in demand, such as RealAudio or VDO(?).
(i have used these over the link with quite satisfactory performance, although
i can't say that the link was under any sizable load at the time).

my interest here is to find interrim solutions, as well as being able to
express in layman's terms to management why the throughput is not what they
expect.

i have found that straight telnet sessions are quite usable if you are not
expecting 5ms latency type response.  (i've been doing admin work on other
satellite linked sites for a while, so i'm used to it).

as it stands, the problems will act as a natural load balance mechanism, albeit
with low throughput per session because not many commercial applications
support user configurable tcp window size.

we are considering the concept of using proxy servers for those data streams
that can easily be broken into separate segments, and have the middle segment
performed by equipment with more modern and/or suitable window sizes and TCP
modifications (RFC's 1323, 20001, 2018).  this will work for some classes of
traffic, but not all.

for the time being, i am telling management that the facility is load balanced,
and a penalty of that load balance is that no one user can expect to see more
than 20-30K bytes/second throughput.

--
[ Jim Mercer    Reptilian Research      jim@...   +1 416 410-5633 ]
[ The telephone, for those of you who  have forgotten, was a commonly used ]
[ communications technology in the days before electronic mail.            ]
[ They're still easy to find in most large cities. -- Nathaniel Borenstein ]

At 14:47 -0500 12/12/97, Jim Mercer wrote:
>we currently have a 2mbit circuit which due to the issues being discussed
>here,
>is highly under utilized.
>
>as such, i am looking for solutions which will help me maximize the
>utilization
>until such point that the solutions discussed here are forwarded and
>implemented.

Could you give us more detail on the nature of the traffic flowing over
this link.  In particular, I am interested in the number of users that
simultaneously access the circuit, and whether the traffic is mainly bulk
data transfer or mainly interactive or near-interactive?


Hans Kruse, Associate Professor and Director
McClure School of Communication Systems Management, Ohio University
9 S. College Street
Athens, OH 45701
614-593-4891 voice,  614-593-4889 fax,  hkruse1@...

i understand that this working group is looking into methods of more fully
utilizing IP over satellite.

i am (as some of you will understand) in the unenviable position of having
actual production systems using IP over satellite for Internet access.

we currently have a 2mbit circuit which due to the issues being discussed here,
is highly under utilized.

as such, i am looking for solutions which will help me maximize the utilization
until such point that the solutions discussed here are forwarded and
implemented.

since the time between recommendations from this group, and the actual
implementation can be quite long, i am attempting to discover what possible
interim measures can be used to increase performance.

i would appreciate any insight that the gathered minds here can provide.

if this message is off-charter, please let me know.

--
[ Jim Mercer    Reptilian Research      jim@...   +1 416 410-5633 ]
[ The telephone, for those of you who  have forgotten, was a commonly used ]
[ communications technology in the days before electronic mail.            ]
[ They're still easy to find in most large cities. -- Nathaniel Borenstein ]

Tom and Enrique,

A while ago, we decided to split the output of this working group into two
separate drafts, one to address standards and best practices and one to
address research issues for improving TCP performance.  The motivation was
to avoid confusing someone looking for information about how best to use
TCP today over satellites.  If the research ideas were in the same document
as the recommendations, someone might confuse the two and try to do
something that perhaps they shouldn't.

What we have is one document that some might describe as a no-brainer (the
standard mechanisms draft) and another that will discuss specific issues
and some possible solutions, some of which may ultimately turn out to be
wrong or useless or unworkable (but that's research).  The second draft is
still still being fleshed out, half of it is still just an outline.  If you
have some research to report on, please post details to the list and we can
work it in.

I hope that the standard mechanisms draft will help to educate consumers as
to what to ask for from their TCP implementors and encourage implementors
to include options beneficial to satellites in their stacks.

We are not going to be advocating any particular research at this point,
just describing the issues and pointing to possible avenues for research.
As I understand the scope of this working group, we are charged with
defining the issues.  If we identify something that requires further
action, then we would probably have to form a follow-on working group or
get a new charter to address that.  I think you raise a valid point and I
would agree that if we find something that is an obvious win for everyone
that we should do our part to support it and help shepherd it through the
IETF process.  We can recommend "well understood protocol changes"
(http://www.ietf.org/html.charters/tcpsat-charter.html).

I believe the standard mechanisms draft fulfills a useful purpose and I
think we did the right thing in spliting the two documents.  TCPSAT is not
chartered to develop a new TCP and, when the working group is finished, it
will not have solved all problems, but we will have taken the logical first
step.

R/
Dan

At 10:33 PM 12/9/97 -0500, you (Lynch, Tom) wrote:
>After careful review of the Draft "Enhancing TCP over Satellite Channels
>using Standard Mechanisms (v01)" we came to the conclusion that the
>document seems to lack a goal/focus.  What are we trying to achieve?
>Now that we have identified the factors that limit performance in a
>satellite based network, and identified different approaches to mitigate
>some of these problems, will any specific recommendations be made to
>change the requirements to the TCP protocol?  Are we going to suggest
>that some of the enhancements that are currently in most current
>releases (such as Fast Retransmit, Windows scaling) be upgraded to
>Required Status? Perhaps it is time to revisit the goals of the group.
>Otherwise this document runs the risk of being short lived and ignored.
>
>
>Thomas J Lynch
>AT&T Laboratories
>tlynch@...
>
>Dr. Enrique G. Cuevas
>Satellite Communications
>International Network Technology Development
>AT&T Laboratories
>cuevas@...
>
>
>

Curtis and the tcp-sat group;
         This is such a good example of the "latency gap" issue that I just had
to comment.  Curtis is 100% right-on in describing what I hope is the goal of
our group.  Knowing full well the complexity and variety of situations in which
our work may be applied, it is vital to identify the set of options to consider
when adapting TCP to a satellite link.  Showing what does (or doesn't) work, and
the reasons some TCP defaults  are  "dumb" and why a "dumb" default in one
situation is "smart" in another is key information.

         However, ... the AT&T comments are literally the real world "out there"
intruding on our little piece of cyberspace.  Who do we convey to the layman
(management, press, etc. ...) that while there are technical issues, "all's
right with the world and the Internet"?  We (technical folks) have to remember
that for all our good work, an active PR "hack" can create lots of "fear and
dread" with little or no effort.  We should also consider vanquishing this enemy
as well.

                                     .....victor
_______________________________________________________________________________
Subject: Re: Purpose of the Draft - Focus of the WG
From:    curtis@... at CCGATE
Date:    12/9/97  9:30 PM

In message <51B1EBA5B2F3CF11820400A0C90379590E7C46@...>, "Lynch
, Tom" writes:
> After careful review of the Draft "Enhancing TCP over Satellite Channels
> using Standard Mechanisms (v01)" we came to the conclusion that the
> document seems to lack a goal/focus.  What are we trying to achieve?
> Now that we have identified the factors that limit performance in a
> satellite based network, and identified different approaches to mitigate
> some of these problems, will any specific recommendations be made to
> change the requirements to the TCP protocol?  Are we going to suggest
> that some of the enhancements that are currently in most current
> releases (such as Fast Retransmit, Windows scaling) be upgraded to
> Required Status? Perhaps it is time to revisit the goals of the group.
> Otherwise this document runs the risk of being short lived and ignored.
>
>
> Thomas J Lynch
> AT&T Laboratories
> tlynch@...
>
> Dr. Enrique G. Cuevas
> Satellite Communications
> International Network Technology Development
> AT&T Laboratories
> cuevas@...


I'm not sure why the document would be ignored.  In a nutshell it says
that there are some really stupid ways to use TCP some of which are
changeable defaults and some of which are built in to specific less
cluefull vendor implementations and there are smarter ways to use TCP
*as is*.  Using TCP *as currently defined* but insuring that your
vendor supports certain RFCs (such as Path MTU Discovery, RFC1323 and
in particular window scaling, and SACK) and making sure these options
are enabled and some configuration done can make a few decimal orders
of magnitude difference in performance.

In considering this as an Informational RFC, this sort of thing
strikes me as *very* useful information.  It describes the worst and
best that can be done using the existing standards.  It is a useful
product of the WG though not nessecarily the only product of the WG.

Curtis

The following is an attached File item from cc:Mail.  It contains
information that had to be encoded to ensure successful transmission
through various mail systems.  To decode the file use the UUDECODE
program.
--------------------------------- Cut Here ---------------------------------
begin 644 rfc822.txt
M4F5C96EV960Z(&)Y(&-C;6%I;"!F<F]M(&9W+65S,#4N:&%C+F-O;0T*1G)O
M;2!O=VYE<BUT8W`M;W9E<BUS871E;&QI=&5`86-H='5N9RYS<"YT<G<N8V]M
M#0I8+45N=F5L;W!E+49R;VTZ(&]W;F5R+71C<"UO=F5R+7-A=&5L;&ET94!A
M8VAT=6YG+G-P+G1R=RYC;VT-"E)E8V5I=F5D.B!F<F]M(&%C:'1U;F<N<W`N
M=')W+F-O;2`H6S$R.2XT+C4Q+C)=*0T*("`@("`@("`@(&)Y(&9W+65S,#4N
M:&%C+F-O;2`H."XX+C0O."XX+C0I('=I=&@@4TU44`T*("`@("`@:60@5D%!
M,C`P.3@[(%1U92P@.2!$96,@,3DY-R`R,3HQ.#HT,2`M,#@P,"`H4%-4*0T*
M4F5C96EV960Z(&)Y(&%C:'1U;F<N<W`N=')W+F-O;2`H-"XQ+U--22TT+C$I
M#0H@("`@:60@04$P-3`T-#L@5'5E+"`Y($1E8R`Y-R`R,3HP,CHT,R!04U0-
M"E)E8V5I=F5D.B!F<F]M(&)R;V]K9FEE;&0N86YS+FYE="`H8G)O;VMF:65L
M9"UE9C`N8G)O;VMF:65L9"YA;G,N;F5T*2!B>2!A8VAT=6YG+G-P+G1R=RYC
M;VT@*#0N,2]334DM-"XQ*0T*("`@(&ED($%!,#4P,SD[(%1U92P@.2!$96,@
M.3<@,C$Z,#(Z,SD@4%-4#0I296-E:79E9#H@9G)O;2!B<F]O:V9I96QD+F%N
M<RYN970@*&QO8V%L:&]S="YB<F]O:V9I96QD+F%N<RYN970@6S$R-RXP+C`N
M,5TI#0H@("`@8GD@8G)O;VMF:65L9"YA;G,N;F5T("@X+C@N-2\X+C@N-2D@
M=VET:"!%4TU44"!I9"!!04$R-#`U,#L-"B`@("!7960L(#$P($1E8R`Q.3DW
M(#`P.C`X.C`P("TP-3`P("A%4U0I#0I-97-S86=E+4ED.B`\,3DY-S$R,3`P
M-3`X+D%!03(T,#4P0&)R;V]K9FEE;&0N86YS+FYE=#X-"E1O.B`B3'EN8V@L
M(%1O;2(@/'1L>6YC:$!A='0N8V]M/@T*0V,Z("(G=&-P+6]V97(M<V%T96QL
M:71E0&%C:'1U;F<N<W`N=')W+F-O;2<B(#QT8W`M;W9E<BUS871E;&QI=&5`
M86-H='5N9RYS<"YT<G<N8V]M/@T*4F5P;'DM5&\Z(&-U<G1I<T!A;G,N;F5T
M#0I3=6)J96-T.B!293H@4'5R<&]S92!O9B!T:&4@1')A9G0@+2!&;V-U<R!O
M9B!T:&4@5T<@#0I);BU297!L>2U4;SH@66]U<B!M97-S86=E(&]F(")4=64L
M(#`Y($1E8R`Q.3DW(#(R.C,S.C$R($535"XB#0H@("`@("`@("`@("`@/#4Q
M0C%%0D$U0C)&,T-&,3$X,C`T,#!!,$,Y,#,W.34Y,$4W0S0V0&UA:6QS<G9B
M+FAO+F%T="YC;VT^(`T*1&%T93H@5V5D+"`Q,"!$96,@,3DY-R`P,#HP.#HP
M,"`M,#4P,`T*1G)O;3H@0W5R=&ES(%9I;&QA;6EZ87(@/&-U<G1I<T!B<F]O
M:V9I96QD+F%N<RYN970^#0I396YD97(Z(&]W;F5R+71C<"UO=F5R+7-A=&5L
K;&ET94!A8VAT=6YG+G-P+G1R=RYC;VT-"E!R96-E9&5N8V4Z(&)U;&L-"@``

end

In message <51B1EBA5B2F3CF11820400A0C90379590E7C46@...>, "Lynch
, Tom" writes:
> After careful review of the Draft "Enhancing TCP over Satellite Channels
> using Standard Mechanisms (v01)" we came to the conclusion that the
> document seems to lack a goal/focus.  What are we trying to achieve?
> Now that we have identified the factors that limit performance in a
> satellite based network, and identified different approaches to mitigate
> some of these problems, will any specific recommendations be made to
> change the requirements to the TCP protocol?  Are we going to suggest
> that some of the enhancements that are currently in most current
> releases (such as Fast Retransmit, Windows scaling) be upgraded to
> Required Status? Perhaps it is time to revisit the goals of the group.
> Otherwise this document runs the risk of being short lived and ignored.
>
>
> Thomas J Lynch
> AT&T Laboratories
> tlynch@...
>
> Dr. Enrique G. Cuevas
> Satellite Communications
> International Network Technology Development
> AT&T Laboratories
> cuevas@...


I'm not sure why the document would be ignored.  In a nutshell it says
that there are some really stupid ways to use TCP some of which are
changeable defaults and some of which are built in to specific less
cluefull vendor implementations and there are smarter ways to use TCP
*as is*.  Using TCP *as currently defined* but insuring that your
vendor supports certain RFCs (such as Path MTU Discovery, RFC1323 and
in particular window scaling, and SACK) and making sure these options
are enabled and some configuration done can make a few decimal orders
of magnitude difference in performance.

In considering this as an Informational RFC, this sort of thing
strikes me as *very* useful information.  It describes the worst and
best that can be done using the existing standards.  It is a useful
product of the WG though not nessecarily the only product of the WG.

Curtis

I know some of you read the November BYTE Magazine article "Fiber in the
Sky", which had a few flaws, but in general wasn't bad.  The new (January)
issue has a letter to the Editor about it (p. 17) that refers to the
infamous LA Times article and (IMHO) a somewhat confusing response by the
BYTE West Coast Bureau Chief.

It might be worth sending a note to BYTE clarifying the issue, identifying
this list and describing the work y'all have done during the past year
(e.g. the draft).  Just a thought.

Cheers,
Eric

PS- I'm too lazy to re-type it here, but I suppose could send one or two
faxes.

After careful review of the Draft "Enhancing TCP over Satellite Channels
using Standard Mechanisms (v01)" we came to the conclusion that the
document seems to lack a goal/focus.  What are we trying to achieve?
Now that we have identified the factors that limit performance in a
satellite based network, and identified different approaches to mitigate
some of these problems, will any specific recommendations be made to
change the requirements to the TCP protocol?  Are we going to suggest
that some of the enhancements that are currently in most current
releases (such as Fast Retransmit, Windows scaling) be upgraded to
Required Status? Perhaps it is time to revisit the goals of the group.
Otherwise this document runs the risk of being short lived and ignored.


Thomas J Lynch
AT&T Laboratories
tlynch@...

Dr. Enrique G. Cuevas
Satellite Communications
International Network Technology Development
AT&T Laboratories
cuevas@...

Hello to the tcp-over-satellite community.

My name is Burt Liebowitz. I am Vice President of Technology at Orion
Network Systems in Rockville Maryland. We are a satellite operator,
selling both space segment and networks. We have an Internet service
called
WorldCast, which provides access to the US Internet for European ISPs.
We have an uplink in Virginia connected via a US ISP to the US Internet.
We transmit to dishes at European ISP sites. The ISP redistributes via
terrestrial circuits to its customers. We provide asymmetric satellite
links, and in some cases one way satellite links with terrestrial return
( a hybrid system).

We have done some work on analyzing TCP performance based on file size,
bit error rate and window size utilizing somewhat idealized models of
efficient TCP transfers. I am particularly interested in any work done
in the field that shows the impact of BER on throughput. I have seen
some articles in the literature but very few that show actual test
results.

I have heard some talk that BER is not an issue on satellites, because
the circuits can be designed to meet any stated requirement. However, my
experience is that we need in the order of 1 db of power for each decade
improvement in BER (after coding). This relates to dollars because power
costs money.

We typically design our link budgets for better than 10 <6> BER, 99.5%
of the time. We figure that another 1 to 2% of the time, we operate
between 10 <6> and 10<10>, depending up the degree of moisture, and the
rest of the time better than 10<10>.  We know that if we increase window
size we can get better throughput but we must also improve BER. I am
extremely interested in references to studies that indicate what type of
improvements are needed i.e. what BER is required to support throughput
going up to the megabit range.

I am also interested in spoofers and the use of proxy servers to enhance
performance over the satellite link. References to papers and or
commercial products would be welcomed.

Thanks

We are going to do an MBone over Satellite experiment in IETF-40.
We will tap into the Mbone and carry one IETF multicast channel over
DirecPC.  Any DirecPC user in the United States can run an Mbone
H.261 application to pick up the video/audio next week.

This is to demonstrate the concept of the satellite network
being the most suitable IP multicast backbone. It helps to
off-load congestions from the Internet and provides certain
QoS guarantee for multicast flows over the space segment.

The technical challenge of MBone over DirecPC includes
unidirectional link routing (UDLR WG) and the integration
with MBone infrastructure.

At HRL we will also compare the video/audio quality received from
DirecPC and from the normal MBone.  If you have the necessary
facility (DirecPC, and a connection to MBone) and are interested
in do the measurement at your end, please let me know.  I'm
interested in collected data from different part of the network.

More information, please see
http://www.wins.hrl.com/people/ygz/mbone-ietf40/.

I'd like to hear your comments and suggestion w.r.t. this.

Thanks!

Yongguang Zhang
UDLR WG co-chair






============================================================================
==
Yongguang Zhang, Ph.D., Research Staff Member (Computer Science)
Hughes
Research Labs, Inc., RL96, 3011 Malibu Canyon Rd, Malibu, CA 90265,
USA
ygz@...   http://www.wins.hrl.com/people/ygz   +1-310-317-5147
(fax: 5695)

Is there anyway this meeting (video & audio) is available in a digital
format, which can be downloaded and viewed later.

Thanks
Ravi

Aaron Falk wrote:

> FYI.
>
> aaron
>
> --
> Aaron Falk    (310) 814-4932
> TRW, Inc
> Electronics Systems & Technology Division
> Aaron.Falk@...



--
Ravi Malghan
Hitachi Data Systems
Tel: (703) 207 7924
Fax: (703) 207 7988
e-mail: rmalghan@...

New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the TCP Over Satellite Working Group of the IETF.

	 Title  : Ongoing TCP Research Related to Satellites
	 Author(s) : D. Glover, M. Allman
	 Filename : draft-ietf-tcpsat-res-issues-00.txt
	 Pages  : 8
	 Date  : 02-Dec-97

     This document outlines TCP mechanisms that may help better utilize
     the available bandwidth in TCP transfers over long-delay satellite
     channels.  The work outlined in this document is preliminary and has
     not yet been judged to be safe for use in the shared Internet.


Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	 "get draft-ietf-tcpsat-res-issues-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-tcpsat-res-issues-00.txt

Internet-Drafts directories are located at:

	 Africa: ftp.is.co.za

	 Europe: ftp.nordu.net
		 ftp.nis.garr.it

	 Pacific Rim: munnari.oz.au

	 US East Coast: ds.internic.net

	 US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to: mailserv@....  In the body type:
	 "FILE /internet-drafts/draft-ietf-tcpsat-res-issues-00.txt".

NOTE: The mail server at ds.internic.net can return the document in
	 MIME-encoded form by using the "mpack" utility.  To use this
	 feature, insert the command "ENCODING mime" before the "FILE"
	 command.  To decode the response(s), you will need "munpack" or
	 a MIME-compliant mail reader.  Different MIME-compliant mail readers
	 exhibit different behavior, especially when dealing with
	 "multipart" MIME messages (i.e. documents which have been split
	 up into multiple messages), so check your local documentation on
	 how to manipulate these messages.


Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

To obtain information about Turbo Internet, at the product level, you may
want to refer to "www.direcpc.com".  For more detailed information about
DirecPC, refer to
"http://www.isr.umd.edu/TechReports/ISR/1996/TR_96-28/TR_96-28.phtml".

Enjoy,

Roderick J. Ragland
Hughes Network Systems
rragland@...

FYI.

aaron

--
Aaron Falk    (310) 814-4932
TRW, Inc
Electronics Systems & Technology Division
Aaron.Falk@...

Hi.

	 I would like to know if anybody in the mailing list has a pointer
to a good technical description of the TCP package (called Turbo-Internet)
used in the one-way satellite link used by DirecPC ?

	 I read somewhere that the DirecPC Network Operation Center (NOC)
was returning ACKs to the web server visited by the user when the data
transmitted by the web server was reaching the DirecPc NOC, not the end
user. (i.e., spoofing is used in their system).  Any details about how it
is done exactly ?

	 Is the dial-up return path used at all to carry TCP segments in
that configuration ?  Or is all the TCP data that enters the user's PC
comes from the dish ?

	 Thanks in advance for any answers and/or pointers.


	 Hugo

===========================================================================
Hugo Jacques
M.A.Sc. Student, Electrical Engineering   web: http://www.ee.ubc.ca/~hugoj
The University of British Columbia        e-mail: hugoj@...
Vancouver, B.C.
===========================================================================

MONDAY, December 8, 1997
0930-1130  Morning Sessions
         TSV  tcpsat     TCP Over Satellite WG

AGENDA (2 hours)


   1. Agenda bashing
      (5 min)
   2. Milestones & Schedule update
      (10 min)
   3. Overview of draft-ietf-tcpsat-stand-mech-01.txt
      (20 min)
   4. Review of Comments on
      draft-ietf-tcpsat-stand-mech-01.txt
      (20 min)
   5. Overview of draft-ietf-tcpsat-res-issues-00.txt
      (20 min)
   6. Review of Comments on
      draft-ietf-tcpsat-res-issues-00.txt
      (20 min)
   7. General Discussion
      (25 min)
   8. Close

--
Aaron Falk    (310) 814-4932
TRW, Inc
Electronics Systems & Technology Division
Aaron.Falk@...

just
testing list

later
dan

Quick note for Keith from the field...

Keith:

Am currently working with a small ISP in northwest Alaska where we are
undergoing a rather embarrassing transition from a 128CIR frame relay feed
out of Anchorage to a 256CIR feed, a jumpt to a 448CIR feed and ultimately
a re-engineered circuit from Nome, Alaska, to Seattle, Washington, running
at 512KBps CIR / 1.024 MBps burst.

Project engineers for this circuit upgrade may be contacted via the
following personnel at ATT Alascom:

Duane Moran -- dmoran@...
Maryann Flowers -- mflowers@...

Duane is your technical contact.  Maryann is your commercial contact.
Most likely, you'll come in contact with Duane first.

Please, at my urging, contact the project manager (Duane.)  He'll be able
to put you in touch with research personnel in both Anchorage and Seattle
who have more information regarding this project.  I will be working with
Duane and with an engineering department contact at ATT to discuss a
solution for dispersion of this network feed within the Seward Peninsula
and Bering Strait Region.  We (the ISP -- nome.net) will be acting as an
interface for the dispersal points according to the model currently under
discussion, and the solution is likely to take advantage of Demand
Assigned Multiple Access systems currently in the end-research phase at
ATT (although a similar system is also in end-research phase at General
Communications Incorporated, aka GCI -- an Anchorage-based IXC for
Alaska.)

Yours (and collaborative partners') succinct summary of the state of
multi-megabit data transfers over satellite frame would be most
appreciated (especially if presented in binary form, i.e. yes or no.)

Thanks a bunch.

Thomas Bohn --  Systems Specialist

Kawerak, Inc: 907.443.4392 -- Direct Desk Line
		 907.443.3708 -- FAX
		 tbohn@...

"Well I roll and I tumble all night long...
  Well I roll and I tumble the whole night long
  Well I woke up this morning and didn't know right from wrong..."

--  Muddy Waters, "Rollin' and Tumblin'"

[finger tbohn@... for PGP public key]

We hope that everyone celebrating the blessings of America and our bountiful
life has a wonderful and safe holiday.  We also give special thanks for the
merciful and compassionate deeds of the Native Americans who saved the lives of
the pilgrims.

Thank you America!



North American Company
http://www.North-American.com
mailto://PublicAffairs@North-American.com
Private and confidential.  This electronic message and
it's attachments are intended solely for the named recipient.

Some empirical data for the pro-satellite position...

As I mentioned earlier, at JPL we have our mobile satellite protocol
testbed running, and are using it to measure TCP performance under various
modifications.  What follows is an example of the type of data we are
gathering.

Our work is meant to reflect a single user on a single hop, such as might
be the case for a mobile user accessing a proxy server at the satellite
groundstation.  In this model of satellite access, the user's bandwidth is
fixed (i.e. we do not model contention for the satellite channel).

Our first tests are with large windows as per 1323.  For one-way delays
less than about 150ms, the bandwidth*delay product is less than 64k, so the
results are the same with or without large windows.  For one-way delays of
150 and above, the results diverge.  The table gives the channel
utilization, defined as the number of information bits transmitted in time
T divided by R*T, where R is the channel rate.  For 150ms and above,
results are given with and without large windows (XXX/YYY) where XXX is the
channel utilization with large windows, YYY without.  Note the greater than
2 to 1 improvement at GEO delays!


Data Rate: 2 Mbps
Channel: Binary Symmetric
TCP Mods: Big Windows
Method:  Netperf 10MB transfer.
MSS:  1460

                                 =======================
                                 | One-Way Delay  ---> |
                                 =======================
              0     50     100       150         200         250         300
|
B  1e-7    92.78  91.68  76.83   63.9/65.7   54.1/48.2   46.4/38.9   46.7/32.6
E
R  1e-8    95.98  94.82  93.26   90.9/77.8   88.7/58.8   82.7/47.7   81.6/39.9
|
v  1e-9    96.94  95.42  93.49   91.4/78.7   89.3/59.9   86.5/48.1   84.9/40.2

    0       96.81  95.32  93.46   91.4/78.9   89.0/59.8   87.1/48.1   85.3/40.3


Note that a channel utilization of 80% corresponds to a sustained
throughput of 1,600 kbps, well above the 512kbps value that is sometimes
quoted as the upper limit for TCP over satellites.

Although the channel utilization is shown in the table, the raw data
reflects the latency and the number of retransmissions, which can be used
to calculate the efficiency in terms of the number of total bits
transmitted per data bit.

We are currently working on :
	 larger initial window size
	 sack
	 scps

and hope to have at least preliminary data in time for the december IETF
meeting.

				 --keith



-----------------------------------------------------------------------------
Keith Scott                                         kscott@...
Jet Propulsion Laboratory
4800 Oak Grove MS 161-260                             (Voice) +1.818.354.9250
Pasadena, CA 91109-8099                               (FAX)   +1.818.393.4643
-----------------------------------------------------------------------------

Form: Memo
Text: (36 lines follow)
Here are a few comments on my first reading of the draft RFC.

Section 2, para 2, 3rd sentence add
"Therefore each ground station is always able to "see" the orbiting
satellite at the same position in the sky."

Page 3 NOISE section 4th sentence
"Typical bit error rates for a satellite link today are in the order of 1
error per 10 million bits (1x10^-7) or better."

Page 4 Transmission Errors section
Delete the first sentence.  It adds nothing to the paragraph and in my
opinion is very negative.

Page 4 Asymmetric Use section
I think this whole paragraph is also negative.  I would at least change the
first sentence to..
"Due to the flexibility afforded by satellite transmission, asymmetric
satellite networks are often constructed."

Page 4 Intermittent Connectivity section
"In non-GSO satellite orbit configurations, ...etc"

Page 6 1st full paragraph 3rd sentence
"Because of the effect of long RTT, the time needed to recover from errors
on a satellite link is longer than for a terrestrial network with shorter
RTT."

Page 7 section 4.1.1 3rd paragraph 4th sentence.
Isn't the idle time 250 ms as the first 250ms were needed to send the data
initially?

Hope these comments help to polish the document.

Thanks Matt

Use Proportional Font: true
Attachment Count: 0