Subject: Re: RoamAbout unit? (was "Re: ietf hosts")

From: Steven Bellovin <[email-masked]>
Date: Thu, 18 Dec 1997 09:54:28 -0500

Just to clarify;-)...
	 
	 Do I correctly infer from this thread that people who buy their own
	 RoamAbout can take it to IETF meetings and (as long as DEC provides
	 their boxes at IETF) use their own RoamAbout in place of those taps on
	 over crowded tables?

Yup.
	 
	 Sounds like a reasonable choice for lots of people, if they can be
	 assured of the service being continued at IETF meetings.

I thought so...

---

From: [email-masked] (Christian Huitema)
Date: Thu, 18 Dec 1997 13:59:17 -0500 (EST)

On Dec 18,  9:54am, Steven Bellovin wrote:
> Subject: Re: RoamAbout unit? (was "Re: ietf hosts")
> 	 Just to clarify;-)...
>

Just a precision.  Do you mean "RoamAbout", or any WaveLAN product ?  And
then, do you mean the 900 MHz version (which cannot be used in Europe) or
the 2.4 GHz version ?

-- 
Christian Huitema
----------
See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/--

---

From: Randy Bush <[email-masked]>
Date: Thu, 18 Dec 97 11:46 PST

> then, do you mean the 900 MHz version (which cannot be used in Europe) or

As mentioned yesterday, any of the family.  And so far, both wavelengths
have been supported.

randy

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Mon, 30 Mar 1998 23:15:11 -0800

My understanding is that the TCP Over Satellite WG is considering the 
	use
	 of spoofing (at least as a research topic).  I presume this means that
	 IPSec and spoofing to improve performance on a long latency satellite
	 network are incompatible.   Is there any way to maintain security and
	 still do TCP spoofing for satellites (i.e., could you elaborate on the
	 evil)?

You're right -- IPsec will not permit window-size spoofing.  To understand
why, imagine that an enemy were to play games with window sizes --
probably sending small ones, but just large enough to avoid tickling the
silly window syndrome code; slamming the window shut (remember that
closed windows are probed very infrequently); opening it wide and then
slamming it shut (against the spec, but is your stack robust enough
to cope?), etc.

It's an interesting question how to have both good security and how
to play such TCP games.  There are other issues between IPsec and
ECN; I spoke at that BoF today.

---

From: Christian Huitema <[email-masked]>
Date: Tue, 31 Mar 1998 23:36:11 -0500 (EST)

On Mar 30, 11:15pm, Steven M. Bellovin wrote:
> Subject: Re: Last Call: Security Architecture for the Internet Protocol to

By the way, it should be noted that the only rationale, if any, for
TCP spoofing in the satellite relays is the inadequacy of the end-to-end
TCP implementation.  The specificities of satellites and their interaction
with transport protocols have been known for more than 15 years, and the
cure is also very well known: use large windows, use selective 
acknowledgments.  The only slightly researchy subject is the possible
use of pacing mechanisms to avoid the swings caused by large windows.
TCP support both large windows and selective acknowledgements.  A user
that opts for end to end encryption will still get good performances
over satellite links if they also select proper TCP implementations.

-- 
Christian Huitema
----------
See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/

---

From: Christian Huitema <[email-masked]>
Date: Tue, 31 Mar 1998 23:36:11 -0500 (EST)

---

From: Christian Huitema <[email-masked]>
Date: Tue, 31 Mar 1998 23:36:11 -0500 (EST)

---

From: Eric Travis <[email-masked]>
Date: Wed, 1 Apr 1998 12:37:30 -0500 (EST)

> over satellite links if they also select proper TCP implementations.

Actually, no... (!)

For one thing, you are assuming that both ends of a transport connection
are aware that they have a path including a long-delay path. Good
assumption 15 years ago, bad today and in the future.

Rather than rehash the problem space here, let me just say that BOTH sides
of a TCP connection must use a "proper TCP implementation" when the path
includes a satellite hop. For ad hoc connectivity this is a dicey
proposition at best; Even if the anonymous ftp server at foo.bar.com 
was RFC-1323 capable, what makes anyone think it can offer appropriate
windows for the available bw-delay product? 

Second, satellite links take far longer to recover from congestion than
their terrestrial counterparts (it turns out to be an r**2 thing with the
increase in ratios of relative delays in the path); 

There are many other little nits that make me disagree with the notion
that the problems are "solved" already. Suffice it to say, my vision
of future "last hop" connectivity to the Internet backbone is going
to be more asymmetric and possibly dirty.

For satellite users with long delays, short of upgrading every TCP
implementation known on Earth (and flying above) and providing omniscient
capabilities to the TCP implementations & applications as to proper
socket buffer sizes something else needs be done for performance
enhancement.

Spoofing conjures up bad images - but there is great benefit to overall
performance to splitting a connection. Spoofing/proxying is not just for
long delay paths, but also for noisy environments (such as
wireless/mobile). It has it's end-to-end downsides, but it's happening
already and should be brought out of the closet - if for no other reason
than to categorize the impacts (positive and negative) to the larger
network.

No need to debate it here, we can take it to tcp-over-satellite 
(exclusively) if you so desire.

Regards,

Eric

---

From: Eric Travis <[email-masked]>
Date: Wed, 1 Apr 1998 12:37:30 -0500 (EST)

Actually, no... (!)

Regards,

Eric

---

From: Phil Karn <[email-masked]>
Date: Wed, 1 Apr 1998 10:33:51 -0800 (PST)

The TCP-over-satellite group is misnamed. It should be called the
TCP-over-large-bandwidth-delay-paths group. Many terrestrial paths now
have bandwidth*delay products as large (or larger) than satellite
paths.

Cable modems are an increasingly important example. One very popular
modem, the Motorola CyberSURFR, has a 27 Mb/s downstream path (limited
to 10 Mb/s by the 10-Base-T interface) but only a 768 kb/s polled
upstream path. Delays in the upstream direction are highly variable,
frequently reaching several hundred milliseconds under evening
load. (Contributing factors: other users doing large uploads and a
cable company that's notably stingy about adding resources).

Analyze a download over such a modem and you can see how large
bandwidth*delay products are not confined to satellite paths. Worse,
most of these cable modems support only one directly-connected host
computer running the Windows 95 TCP/IP stack. This has spawned a minor
cottage industry in programs to increase the TCP receive window size
in the W95 system registry. But the W95 stack doesn't support window
scaling, so 64K is the limit. The only solution to the problem is to
get Microsoft to update their stack, as difficult as that may be.

(Suggestions that the cable modems should silently proxy every TCP
connection will be greeted with derisive silence.)

--Phil

---

From: Phil Karn <[email-masked]>
Date: Wed, 1 Apr 1998 10:33:51 -0800 (PST)

--Phil

---

From: Eric Travis <[email-masked]>
Date: Wed, 1 Apr 1998 12:37:30 -0500 (EST)

Actually, no... (!)

Regards,

Eric

---

From: Christian Huitema <[email-masked]>
Date: Wed, 1 Apr 1998 14:10:43 -0500 (EST)

Phil,

Yes, this really is a TCP problem.  The classic objections to end to end
solutions are:

1) Both systems need to be able to handle long windows. No question
   there; you will only go as fast as both ends allow.

2) Using long windows is harmful in some cases.

This second objection is actually the root of the first one.  If it is
harmful in some cases, e.g. low speed modems, then it won't be deployed
everywhere, and we will have to hack our ways through horrible
proxying solutions.

The two solutions that apply to TCp are the long window extensions and the
selective acknowledge extensions.  There is no question that using
selective acknowledge result in better performance in all environments,
including low speed links.  I would thus expect that selective acks
will be implemented everywhere in the near future (ping your favorite
vendor).

The problem that remain is thus the possible cost of using large
windows.  The arguments that I have collected so far are:

1) Per packet overhead is increased. Using large windows increases
   the likelihood of resuing the same sequence number, which implies
   a need for a timestamp option, and increases the overhead by
   about 6 bytes per packet.

2) The window option has to be negotiated at the beignning of the
   session, at a time when you don't know whether you will actually
   need it.

3) Using large windows allow the sender to send a shockwave of
   packets through the Internet, which can swamp intermediate 
   routers.

4) Using large windows may lead to large buffer requirements.

As Craig Partridge mentioned, the buffer requirement is  red herring.
In fact, the congestion control algorithm will reduce the window size to
what is effectively needed.  Implementors can then use proper local
control to match buffer allocation to these needs.

The three other problems could be addressed by a working group.  There
should be a way to switch in and out of large window mode within the
life of a connection.  One can easily imagine only sending time stamps
when the number of packets in a window passes a threshold, which would
fit a "use it only when you need it" requirement.  One can also
imagine a negotiation option when the receiver essentially opts for
an "infinite" receive window if it has received the assurance that
the sender uses a proper implementation of congestion control.  One
can devise a pacing option that obliges senders to abide by some
rate limitation.

These three points can in fact make it in the charter of a new
"Better large window TCP" working group.

---

From: Christian Huitema <[email-masked]>
Date: Wed, 1 Apr 1998 14:10:43 -0500 (EST)

Phil,

---

From: Phil Karn <[email-masked]>
Date: Wed, 1 Apr 1998 10:33:51 -0800 (PST)

--Phil

---

From: Christian Huitema <[email-masked]>
Date: Wed, 1 Apr 1998 14:10:43 -0500 (EST)

Phil,

---

From: Phil Karn <[email-masked]>
Date: Wed, 1 Apr 1998 12:59:06 -0800 (PST)

I fully agree. TCP window advertisements are supposed to show how much
buffer space the receiver has available. The receiver should not have
to artificially limit its window because of network considerations --
that's the function of congestion control on the transmitting end.

One problem we do have with the existing TCP congestion control
mechanism is that the sender will increase its congestion window all
the way up to the offered window as long as no packets are lost, even
if all those extra packets just pile up in a queue at the bottleneck
router. Various ad-hoc methods involving real-time bandwidth/delay
measurements have been tried to solve this problem, but they don't
seem to work really well because of measurement noise (competing
traffic, route changes, etc).

Signalling congestion by deliberately dropping packets when buffer
space is still available has always bothered me. There has to be a
better way. Besides, I'm of the opinion that there's just no
alternative to having lots and lots of router buffering, especially on
high speed/long delay links. If a TCP sends a packet into a
bottlenecked path with generous link buffering, the worst that happens
is that the packet waits in the queue for awhile. The link continues
to pass traffic at full capacity. But if TCP timidly shrinks its
congestion window to avoid packet drops in memory-starved routers,
that increases the chance of the link going idle even when the TCPs
have traffic to send.  Idle link time is gone forever.

Explicit congestion notification would help considerably.  This
doesn't necessarily require the definition of new bits in the IP and
TCP headers; you can actually do quite a lot with the oft-maligned
ICMP Source Quench message. I've found it quite effective in the
common case of a host on a private leaf Ethernet sending data through
a dialup router to the outside world. It certainly reacts more quickly
than a mechanism that requires a far-end turnaround of the congestion
bit.

Phil

---

From: Phil Karn <[email-masked]>
Date: Wed, 1 Apr 1998 12:59:06 -0800 (PST)

Phil

---

From: Phil Karn <[email-masked]>
Date: Wed, 1 Apr 1998 12:59:06 -0800 (PST)

Phil

---

From: [email-masked]
Date: Thu, 02 Apr 1998 11:48:06 -0500

> than a mechanism that requires a far-end turnaround of the congestion

Wow.  Full circle time.  Didn't modern TCP congestion control come
from Van Jacobsen's observation that 98% of the time, a lost packet
was due to router buffer overflow, and thus should be treated as
an implicit ICMP Source Quench?

I guess the Jargon File was right about the Cycle of Reincarnation -
currently, we're just finishing up pulling 3 zillion 10-baseT runs
to replace the one thinwire run that replaced the 3 zillion CBX data
lines... ;)
-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech