Subject: Re: pilc minutes for IETF 48

From: Vincent Magret <[email-masked]>
Date: Tue, 03 Oct 2000 10:11:02 -0500

Reiner Ludwig wrote:

> At 13:42 18.09.00 -0500, Vincent Magret wrote:
> >Regarding the discussion on the LL-TCP, the draft specifies that it is
> >recommended to use  link layer information when possible. This can only work
> >for the mobile node and the supervisor host. For the correspondent or server,
> >how can this node have access to link layer, since it is not connected or
> >linked to the wireless network?
>
> No entity above the link layer needs to have access to link layer
> information to solve the problem of link outages. Please, check the
> reference to my thesis that I had sent in one of my last mails.

This is one point of view. If no other entity has notion of the link outage, what
are the possible situation:
1. the source entity will continue to behave as is the link was still up (which is
a waste of resources)
2. the link layer will stored packets (hard state, does not allows the mobile node
to got via another entity)
3. the link layer will droppred the packets (pretty much useless)

>
>
> >There is indeed a need of having a message sent from the edge node (i.e. the
> >supervisor node) to the fixed node to inform this latter about the new status
> >of the link.
>
> I don't think so.

Again, it is a point of view.

>
>
> >I don't like the idea of having packet store in the supervisor node
>
> I wrote that packets are stored at the link layer sender.

Well that a pure hard-state solution, you don't allow a lot of mobility.

>
> >because it
> >is somehow an hard state situation. the mobile node can not "resume" its
> >connection with another supervisor node.
>
> I don't understand your notion of a supervisor node nor do I think that
> such a node is needed, assuming you mean that this node sits above the link
> layer. All that is needed is a plain old link layer protocol which of
> course is hard state.
>
> ///Reiner

Vincent.

---

From: Vernon Schryver <[email-masked]>
Date: Fri, 13 Oct 2000 09:34:09 -0600 (MDT)

> From: Reiner Ludwig <[email-masked]>

> ...
> So let's stay with that example since 9600 bit/sec (sync. = 1200 bytes/sec) 
> is exactly the ideal (no errors on the link) bit rate you get on 
> state-of-the-art wide area wireless networks: IS95 and GSM.
>
> Even if you flame over telco networks so much, if you really need to rely 
> on wide area coverage (beyond nation-wide) then these networks are 
> state-of-the-art.
>
> When travelling I (and so do many other people) always and frequently use 
> GSM to download e-mail from our Intranet and if I really need a piece of 
> info I do HTTP. Believe it or not, there are even situations where I have 
> to telnet, and it works OK.
>
> I set my MTU to 1500 bytes since I'm mostly doing bulk data stuff and want 
> to get highest throughput (I almost never do telnet and bulk data at the 
> same time ;-). Now, the time it takes to transmit a 1500 bytes segment and 
> the returning 40 bytes ACK over 1200 bytes/sec is about 1300 ms (not 
> counting the PPP framing overhead). Like it or not, but for GSM we need to 
> add another 200 ms latency (propagation delay if you prefer) *one-way* over 
> the GSM hop. We are at an e2e RTT of 1700 ms by now. Adding a worst case 
> Internet RTT of 500 ms which is not unlikely gets us to 2200 ms. Because I 
> want to make sure that the link is always utilized you must allow me to 
> queue at least one packet. Thus, we need to add another 1300 ms for the 
> queueing delay of one single packet.
> => a sum of 3500 ms.
>
> But I don't mind because I really need that e-mail to be downloaded and 
> it's not so bad after all. Even telnet is acceptable if I really need to 
> get something done.

It does not matter whether you label such fundamentally broken services
state of the art, by appointment to the king, or anything else.  It is
simply impossible to get people to use such services in the ways that make
your conclusions valid.
Aamong the invalid assumptions are

  - since X is the best that can by done with Y from industry, consortium
   or vendor Z, therefore people want and will pay to do X a lot.  It is
   not only the telcos and telco suppliers that use such reasoning,
   although they perfected it before the computer people arrived.

  - that other than less than an insignificant number of people will ever
   use telnet to talk to an HTTP server or even conceive of the possibility.
   You and I do, but we don't even begin to count.

  - email over such links to such phones needs 4X MSS of buffering in
   the routers.  How big is the screen on your phone, and how much fun
   would 99.99% of users have trying to read an SMTP (or POP or IMAP)
   message that could use 4X MSS?

  - that people have changed since they rejected 500 ms delays 10-15
   years ago and will now embrace them.

> As I write this e-mail, I'm dialing in via a landline modem with 28.800 
> bits/sec which should still be a commonly found link speed. Modems usually 
> have a *one way* latency of 50 ms (depending on the manufacturer you can 
> find much higher numbers!). Doing the same math gets you to a sum of about 
> 1500 ms. Now I mind even less because 28.8 kbit/sec is OK for e-mail, WWW, 
> and telnet.

Yes, and why don't v.34 modems have 30 KBytes or more of buffering?
Why haven't the salescritters that assure us that v.34 modems are really
56 Kbit/sec because we all know that v.42bis gives 4X put another $1 of
buffering in their modems?  One answer is that 90% of consumers cannot
tell the difference between surfing the web at 28-40 kbps with v.34+v.42bis
and using a true 56 kbit/sec, but they do notice that any extra buffering
hurts a lot.

> That's why I can't agree with what you wrote above: "delays of 500 
> milliseconds or more will be considered practically useless"

Agree or not as you like; for anything except email and by anyone except
ubber geeks, it is a fact.  We "have been there and done that."  Delays
of 500 ms or more were found practically useless for interactive applications
10 or 15 years ago by most people.  With their home PC's now running at
6 Mbit/sec and less than 20 ms, they will not and cannot care whether a
GSM phone with 1700 ms is sold by telcos as state of the art or required
by PTT regulations.

> By the way, it's not always the telcos and the modem vendors that are 
> responsible for excessive queueing. Check out the BSD operating system. By 
> default it happily allocates a 50 packet large output buffer for a PPP 
> interface. Given a TCP receiver window of 8 or 16 KBytes, most of those 
> bytes will sit in BSD's output buffer. And then we are talking about RTTs 
> of several seconds! See, e.g., 
> http://iceberg.cs.berkeley.edu/papers/Ludwig-Sigmetrics99/index.html

You're concluding based on too little data.
The commercial PPP code I wrote and caused to be shipped on a system that
used the BSD TCP stack to several 10,000 customers didn't do that.
Moreover, I caused that commmercial UNIX system to ship with a 30 KByte
default TCP window in about 1988 and a 60 K window in about 1993.  (That
is related to my sad tales of woe concerning Ethernet-FR routers with 50
Kbytes of buffering.)
When the company's heavily flogged voice/UDP/IP-multicast application ran
over PPP, it configured a PPP queue length of three hundred (300), but a
tiny MTU and also marked its packets to allow the three kinds of ToS
queuing in the PPP driver to do their things.  (1 kind of ToS queuing was
the IP TOS byte.)
Still more, that particular PPP implementation supported a kind of
multilink that causes packets to be re-ordered, which is where I got my
prejudices about links that re-order and the results on TCP.

> Yes, I know that there are per route metrics that BSD4.4 uses to avoid 
> that. But those metrics are discarded after each PPP session (when the 
> route goes down) so that does not help much.

The 4.4BSD PPP code is very primitive.
Customers forced me to make my PPP code configure routes when links came up.

> So, you haven't convinced me that the last version of the rule-of-thumb is 
> broken.

What you, I, the bosses and sales people at telcos and telco suppliers
think does not matter.
It has been known for 30 years that people start refusing to use
interactive computer applications when delays reach 5 seconds.
See those ancient studies of timesharing systems.

It has also been known for at least 10 years that 500 ms of modem delay
on interactive applications is intolerable to the vast majority of users.
Look at the history of the Telebit corporation.

Vernon Schryver    [email-masked]

---

From: [email-masked]
Date: Sun, 15 Oct 2000 23:39:33 +0330 (GMT+03:30)

I'm not taking sides with neither Mr. Schryver nor Mr. Ludwig
on the issue of how best to optimize TCP delay performance 
over wireless links.

However, I'd like to point out one thing that Mr. Schryver and
many Americans fail to recognize because they may not be witnessing
the explosive growth and the convenience of sending short alpha-
numeric messages (SMS). The lesson is: many applications needn't be 
interactive. Of course Mr. Schryver is right and all the research 
about maximum latency for interactive applications is still valid
today: response times > 500 ms will not be accepted by users.

But email, to cite one example, is NOT interactive. It's only so
when you log on through your home phone line. But a cellular phone is
not quite an ordinary phone. It is also a small computer and it's
always connected (namely through the cellular control channels).
Therefore, the idea is to deliver email directly to the mobile in
which case latency is simply not an issue. Taking another example:
ordering something doesn't necessarily require an immediate feedback 
across the network, either.

Finally, don't forget that a cellular phone is already equipped for
interactive applications when the need arises: just use the voice 
channel. Now, I'm not a firm believer in voice browsing in light of 
all the time I've wasted in recorded-voice menu trees, but I do
think the user experience could be made much more productive than
what is commonplace now. And then there are call centers, of course.

With all this, I am not saying you should not minimise delay and I am
not saying that interactive applications are not important. All I am
saying is that you shouldn't completely dismiss TCP for systems and 
links where you can't meet the 500ms response time requirement. There
may be uses even for that.

Stefan Wiesendanger

DE-TCOM
Swiss Federal Institute 
of Technology, Lausanne

---

From: Vernon Schryver <[email-masked]>
Date: Fri, 20 Oct 2000 13:16:20 -0600 (MDT)

> From: Bill Yeager <[email-masked]>

> I think we agree 100% about the underlying TCP issues.

Probably.
More than that, I think the telco people have come around, except that
they're unwilling to let go of the premise that wireless phones will
be the solid state equivalents of WE 500C's but will still be usable
for all of the applications of a PC or PDA.

>                                                        I do some work on this
> link layer stuff too from time-to-time too. 
>
> Do look at this URL. It tells you what is happening in the App world. I do
> believe that the phone viewed as a dumb text terminal is dead or very quickly
> dying. We are back in 1983 just before the Mac hit the markets and killed off
> the desktop terminal business. The big companies that did not listen are no
> longer in the business. 

I don't think it's a coincidence that the Telebit Trailblazers appeared
about the same time.  The revolutionary idea of the TB was not the fancy
modem protocol, but putting a real computer and vast amounts (for that
era) of memory into a dial-up modem.  Modern "state of the art" wireless
telephones are equivalent to the 3270 emulators for PC's that were so
popular in the same era.  Many people still believed that 3270 still had
a future, or that the future of PC's had something to do with SDLC
connections to glass houses where all of the real computing would be done,
controlled, monitored, billed, etc.

> Change is in the air. It's super stuff:
>
> http://www.washingtonpost.com/wp-dyn/articles/A28462-2000Oct17.html

Yep.

Except that the notion of video phones is just as lame now as it was 25
years ago when AT&T demonstrated them.  The reason video phones are still
not used, after nearly 10 years of cheap or free (i.e. bundled) good,
working products, is that people don't like video calls most of the time.
When humans aren't close enough to smell each other, they prefer the
greater privacy and safety of yelling from a safe distance.  (see recent
literature about what happens to chimpanzees that get too close to the
wrong troop and aren't big enough to keep from being eaten)  In other
words, the people I work with really don't want to see me for the first
several hours of the day before I'm dressed, and vice versa.

See also recent talk about the usefulness of the MBONE to IETF meetings.