Subject: pilc minutes for IETF 48

From: "Falk, Aaron" <[email-masked]>
Date: Fri, 8 Sep 2000 09:39:25 -0400

Performance Implications of Link-layer Characteristics (PILC) Minutes

August 2, 2000, Pittsburgh, PA

Reported by Jim Griner ([email-masked])
Edited by Aaron Falk ([email-masked])

Charts and documents are available from the PILC Web page at
http://pilc.grc.nasa.gov

************

Aaron Falk opened the meeting at 3:30pm and reviewed the agenda,

  Agenda bashing, with no comments

milestones & status

  TCP over Wireless draft.  The working group charter specifies that
  PILC will produce a 'TCP over Wireless' RFC that is a meta list of
  the existing PILC recommendations. This was reported in Adelaide as
  being completed in October 1999 because Aaron had confused it with
  the LTN draft. Actually, it requires some work. Gabe Montenegro has
  volunteered to sync up with the WAP forum to see if we can build
  this document on a work in progress that already exists in that
  body. The document should be only 3 or 4 pages long and should go to
  wg last call by January 2001. Gabe noted that there is currently no
  buy in by the WAP forum as yet, he will attend a forum meeting in
  September and try to resolve. Several members of WAP were in the
  room and volunteered to assist if needed.
			
  ERROR draft. A rough poll was taken indicating the group felt ERROR
  was ready for wg last call.

  SLOW draft. One of the SLOW authors wanted to incorporate some
  additional comments before submitting the draft for wg last
  call. When polled, there was no clear consensus of the group. Will
  see what comments come up on mail list during last call. Last call
  should take place in September. There was some discussion about
  interactions between slow and errored networks and that there should
  be a way to document interactions when you have multiple
  characteristics in a network. In particular, it was pointed out that
  these interactions are not well understood. However, most of the
  understood ones exist in some of the PILC documents (ERROR, SLOW,
  and LINK). It was suggested that appropriate cross references be
  added to ensure readers of one document are aware of relevant
  interactions described in another document. Suggested this issue
  gets raised on the list to see if there are interactions that need
  to be captured somewhere. (Some interactions were captured in
  RFC2488 but these are appropriate for all environments since that
  document focuses on long delay links.)

  Updated Working Group Milestones

    Aug 2000: ERROR (BCP) to working group last call
    Sep 2000: SLOW (BCP) to working group last call
	        PEP (Informational) to working group last call
    Nov 2000: LINK (BCP) to working group last call
    Jan 2001: TCP over Wireless (BCP) to working group last call
	    
    Note: ASYM is in limbo right now until we get an updated draft. 

Phil Karn - LINK document status

  Placing emphasis on end-to-end model. The multicast section is still
  incomplete. Didn't add much to this revision of the
  document. Assymetry section overlaps with asym draft. May rip out
  section on QoS because there may not be much well understood advice
  that can be given. Document still needs text on: 

    o) delay interaction with tcp
    
    o) link layer retransmission 

    o) does the subnetwork need its own routing mechanism?
	
    o) security 

  Comments: Dan Grossman thinks there is some parts of QoS that are
  not overlapping with diff serv, and will provide some text.

John Border - PEP document status

  Didn't receive many comments on -02 draft. Draft-03 released prior
  to this meeting. A disclaimer was added to say it is an overview
  document and does not include all PEP mechanisms. Document needs
  text on:

    o) section 3.6 on protocol boosters
    
    o) section 4.4.1 pep scalability implications 

    o) section 4.4.2 and 4.4.3 multi-homing (maybe delete these
       section if no input received)  

    o) add DoCoMo examples section, from DoCoMo draft
	
    o) W-LAN section needs text

  Plan next release (-04 draft) at end of September

Aaron - PEP comments

  PEPs are being used in many environments, and we ignore them at our
  peril. One reason this document is being written is that we need to
  show what the downsides are to using peps. Outside organizations who
  are using these types of mechanisms (such as WAP) are being directed
  to pilc by the IESG so that they can understand how the IETF views
  these mechanisms. The PEP document is the place to show the problems
  of using PEPs.  We need more information from members of the working
  group to add to the document. Specifically, we have not received
  adequate comments from an architectural perspective. Geoff pointed
  out that things like multi-homing are being  used as a surrogate for
  reliability. 

  Joe Touch suggested to limit PEP document to IP layer discussions,
  rather than the link layer problem. John Border noted that we were
  deferring link layer mechanisms to the link document, due to the
  scope of pep. There was also a comment mentioning that PEPs are
  being used to put QoS in wireless links, and maybe need to include
  this in PEP.  

Discussion on DoCoMo draft (draft-inamura-docomo-00.txt)

  Aaron noted that DoCoMo would like to publish this as informational
  RFC, but we don't want to get in a mode of publishing RFCs each time
  someone does this and requested input from the group.

  A speaker noted that the recommendations are pretty generic and
  suggested the working group use this as a starting point for the TCP
  over wireless document, or as an appendix to this document.  Aaron
  suggested it might be necessary to take the simulation results out
  in order to use this document for the TCP over wireless
  document. Another speaker suggested using path MTU discovery instead
  of fixing it at 1500.  Question: Maybe your tcp stack in the Opnet
  simulator is not the best TCP.  Have you run this on real stacks,
  rather than on a simulator.  Imaura - yes they have, but no
  published results.  

  Aaron noted that another alternative was that the DoCoMo would be
  sent forth as informational, and would not be a recommendation. Tim
  Shepard asked why would one want to disseminate this information?
  Doesn't seem to make sense to have multiples of TCP/some link
  technology.  Is this advice on how to tune TCP for the handset?
  Response from author: yes.

  Comment: This shows that tcp stack works over wireless error prone links.

  Comment: Doesn't think these results are any different from what a
	   modern TCP stack does anyway.

  Gabe: This is similar to what was done in ecn document

  Comment: Thinks this should be published in academic journals, and
	   not as an RFC

  Question: What bandwidth was used in the simulations?
  Imaura: 384kbs
  Comment: Doesn't think this is realistic, since this is only the
	   rate if you are the only one in the cell. WAP is designed
	   to use slower links.

Discussion on Long lived TCPs draft (draft-magret-pilc-lltcp-00.txt)
	
  Comment: this is probably not a good idea -- leads to ICMP flooding.
  Also, if there is a long outage you do want to go through slow start
  again, because the network has changed.  There are better link level
  solutions to this problem.

  Question: Why do you need a proxy and not just use end-to-end signaling?
  Response: The supervisor is in a better position to determine
	    if there is an interruption.
  Response: In this case you need a proxy, and can't do it end-to-end.

---

From: Mark Allman <[email-masked]>
Date: Tue, 19 Sep 2000 10:09:26 -0400

> As far as robust wireless TCP goes, you are absolutely right that
> good service requires a maximum RTO shorter than the standard 64
> seconds.  What is that value in your TCP-Eiffel?

Why should the maximum RTO be less than 64 seconds?  If the RTO gets
to that point it was because of exponential backoff.  So, one of two
things has happened...

  * Extreme congestion.  In this case you want your RTO timer to be
    backed off to a large time to avoid aggrivating the congestion
    even more.

  * An outage.  In this case, it is potentially painful when the
    link is re-established because you have to wait for some (likely
    large) amount of time before re-starting transmission.  So, for
    this case, we'd like to have a lower maximum RTO.

But, how does the end host figure out which situation it is in?
There may be heuristics, but it seems to me that having an explicit
mechanism that "kicks" TCP in the second case is likely the way to
go (i.e., an ICMP or holding on to the last segment(s) to trigger
the restart of the connection).

allman

---
http://roland.grc.nasa.gov/~mallman/

---

From: Vernon Schryver <[email-masked]>
Date: Thu, 21 Sep 2000 10:38:26 -0600 (MDT)

> From: Nitin H Vaidya <[email-masked]>

> ...
> Some folks seem to be arguing that we can solve the errored-link
> problem at the link layer by doing ARQ-for-ever & differentiating
> between TCP and UDP.
>
> I have seen some of the papers which show that link layer
> retransmission can solve the problem in some environments - I
> agree that "limited" ARQ can help reliable flows ...
>
> ... however, I am not convinced that retransmitting for 64 seconds
> or some such large interval of time is always terribly useful.
>
> Even if we grant (for the sake of the argument) that this
> might always improve throughput of a TCP transfer, is that
> necessarily better from a user's perspective ?

What is the alternative?  For TCP, the choice is among ARQ, retransmissions
by the hosts, and breaking the connection.
The only valid argument against ARQ that I've heard are the potential
congestion problems and bandwidth wastes of having both link-layer ARQ
and TCP retransmissions.

In other words, the reason it makes sense to do ARQ on TCP while dropping
drop broken UDP packets is that UDP applications must tolerate out-of-order
and missing packets.  TCP is a reliable stream protocol.  You canot drop
or change even a single bit.  A single drop or rotten bit "MUST" stop the
whole TCP stream until it is corrected either by link-layer ARQ or an
end-to-end retransmission.

> May be, for some TCP connections, response time is also relevant.

Yes, response time matters, but if the link layer can't pass a particular
TCP segment, then the link layer can't pass that particular TCP segment
and any later bits in that TCP connection are also blocked.
Moreover, I hope that except in extremely rare cases, if one particular
segment won't fly for 64 seconds, then no other TCP segments or UDP/IP
packets will fly, that the whole link is busted and not simply filtering
a particular bit pattern.

Unlike voice, TCP and UDP are all or nothing (modulo proposals for UDP)
stream and packet protocols, respectively.
Most Internet applications are unlike plain ol' telephones, and
cannot tolerate getting some of the right bits plus a few wrong bits.

> What if we are looking at a web user who gets impatient and
> starts clicking "reload" every 10 seconds? Or, gives up
> and decides to look up some other web page ? The work done
> in buffering and retransmitting-to-eternity may be wasted/redundant
> in this case.

Consider what happens when the web user clicks 'reload'.

> The point is that there is something of a continuum between
> "reliable" and "non-reliable" flows, and a greater granularity of
> information is necessary to do the right thing at the link layer.
> If such information is not available, why not use
> a generic feedback mechanism to inform the transport layer (e.g., ICMP),
> and let each transport layer (or application) do what it deems best.
> (I am not suggesting that we discard ARQ - the feedback can be used
> in conjunction with limited ARQ, or when limited ARQ fails).

If the radios won't pass the data, then who are you going to inform of
what and what do you want them to do about whatever they're told?  In the
64 second ARQ example, what do you propose instead?  Do you want the HTTP
server to break the TCP connection?  Retransmit?  Not retransmit?

In other words, please reconsider the famous "End to End Principle."

> Also, it may not be possible to reduce non-congestion losses
> to a negligible level in all wireless environments. Even if we
> somehow manage this in the last-hop wireless scenario, in
> multi-hop mobile environment, this may not be practical - here, we
> may have frequent losses due to route changes (carrying the
> "fully reliable ARQ" argument to this case would require the
> network layer to be "fully" reliable too!).

Routing changes in the familiar part of the Internet do not necessarily
imply packet loses.

Vernon Schryver    [email-masked]

---

From: Nitin H Vaidya <[email-masked]>
Date: Thu, 21 Sep 2000 15:33:36 -0500 (CDT)

hi Vernon:

  >> From: Vernon Schryver <[email-masked]>
  ...

  >> and any later bits in that TCP connection are also blocked.

This presumes a single reachable wireless host - not true in general.
If TCP segment to host A cannot get through, the link layer may be
able to pass bits to some other host ?
Of course, I am assuming that the wireless channel is shared between
several hosts (if you have assigned fixed slots to a given host, then
the above argument does not apply).

A related issue:
The buffer space for the packet that sits there for a long time
could be used for other packets that are destined on more
reliable channels (i.e., to other hosts). 
Again, this presumes that buffer space is a shared resources, and
not pre-allocated on a per host basis.

  >> a particular bit pattern.

Like I said above, even if the channel to a given host may be busted,
the channel to another host may be fine.

  >> cannot tolerate getting some of the right bits plus a few wrong bits.

I think it is not reasonable to assume that because existing
applications behave in a certain way, future applications will
behave the same way. Older applications may not have been written
for error-prone links. What prevents me from incorporating redundancy
in an UDP stream? (such proposals have been made for multicasting, by
the way, but for other reasons).

By the way, since you are contrasting "voice" with "TCP/UDP", I guess
you are ignoring voice-over-IP as a potential application for wireless.

  ...
  >> what and what do you want them to do about whatever they're told?  In the

Consider this picture:   

     A --------------- B .... C

where A is sending data to C, and link B-C is wireless.
Even if link B-C is experiencing errors, B can send a message
to node A. There have been several proposals on this theme.
Of course, your point is valid if C were sending data
packets to A.

  >> server to break the TCP connection?  Retransmit?  Not retransmit?

Breaking the TCP connection may be a reasonable option (it all
depends on the application).

  >> In other words, please reconsider the famous "End to End Principle."

Can you please elaborate on that?
Do you mean that the "end-to-end principle" may not be valid anymore
(so we need to reconsider it), or have I ignored the end-to-end principle?

  >> Routing changes in the familiar part of the Internet do not necessarily

Protocols currently being proposed/implemented for ad hoc networks
do result in plenty of packet losses on route changes.

- nitin

---

From: Vernon Schryver <[email-masked]>
Date: Thu, 21 Sep 2000 15:38:47 -0600 (MDT)

> the above argument does not apply).

It seems as if you are assuming that link layer ARQ treats the stream much
as TCP does a single TCP connection.  I don't see why link layer ARQ cannot
transmit and retransmit upper layer packets (IP) independently of each
other.  TCP/IP and UDP/IP are not voice that cannot tolerate re-ordering.
All IP applications are required to deal with out-of-order IP packets.
TCP does not like its segments re-ordered but it does cope.
Any UDP application must also cope with out-of-order delivery.

See also TCP SAK, which allows TCP to retransmit smarter than go-back-N.

> not pre-allocated on a per host basis.

I suspect you're also assuming that the buffer space is a simplistic
ring buffer of bytes instead of a more sophisticated structure
that supports continuing to retry packet N while receiving and
passing on packets N+1 through N+many.

> the channel to another host may be fine.

Would you do ARQ for a bunch of mobile stations in concert, so that if
one packet to one station doesn't get Ack'ed, then all packets to all
stations stall?  If not then I don't understand what you mean.  I hope
that the link between each pair of stations (whether one mobile and one
fixed or a pair of mobile or a pair of fixed) would be handled
independently of the links between all other pairs of stations.

> behave the same way.

That sounds like the familiar wireless "all the world is going to change
to accomodate wireless as it was seen in 1997" thinking (yes, 1997 or
maybe 199).  Applications will change, but wireless link layers will do
far more changing, and will end acting more like a land line.
Land data lines started out about where wireless data is now, and
they got to where they are now for good reasons.  Yes, the physics of
wireless will always differ, but the services offered to upper layers
will converge.

>                      Older applications may not have been written
> for error-prone links.

The reason we have link layer CRC's, FCS's, and FEC is because in the last
40 years it has been found better to put error detection, correction, and
recovery below the applications and even mostly below transport.  However,
there are plenty of applications that tolerate the only errors that can
get past UDP (esp. various voice/IP for the last 10+ years--yes, 10+ in
my personal experince)

>                        What prevents me from incorporating redundancy

UDP packets can be dropped, but you wrote about TCP.
Besides, each UDP packet is an all or nothing proposition.
Your only choice is between link-layer ARQ and discarding UDP packets,
or some combination of the two (e.g. ARQ for a while and then give up).

> you are ignoring voice-over-IP as a potential application for wireless.

No, I was pointing out that unlike plain old telephone where plenty of
wrong or missing bits are just fine, broken TCP and UDP bits must either
be discarded and retransmitted (at least for TCP) or you have link layer
ARQ (and/or FEC).

> Of course, your point is valid if C were sending data

People exerienced with IP stuff generally assume there are several links
between then ends.  I think most would also treat A<-->C, A<-->B, and
B<-->C as three independent cases.  IP multicast complicates that a little,
but only a little.

> (so we need to reconsider it), or have I ignored the end-to-end principle?

Anything that wants to tell the TCP or UDP state machines at either
end of a path something about one link in the middle of the path
is certainly stretching the end-to-end principle and probably completely
ignoring it.

> do result in plenty of packet losses on route changes.

I bristle at that sentence and most at the phrase "ad hoc networks" that
seems to suggest that wireless links are revolutionary as far as IP
is concerned.
I don't quite know why, but IP over wireless has a history claims that
wireless links are completely different from any kind of links that IP
has ever seen before.
The incredibly ignornat claim I recently found in a trade rag that TCP/IP
cannot run on a 9600 bit/sec link and therefore we must use WAP is merely
an extreme example of the syndrome.

As I see them, wireless links are merely very fast (yes, fast) old style
modems with slightly higher than usual error rates (yes, only slightly).
The errors wireless people worry about wireless modems don't sound much
different from what happened when someone picked up an extension on your
TCP/IP/SLIP/modem connection, not to mention the purely analogy phone
lines that made Telebit Trailblazers so popular.  Even the choice between
ARQ (e.g. Trailblazer or years later, v.42) and ~u or other noise (type
103 through various 9600 bps) is familiar.

---

From: "Al-hussein Abou-zeid" <[email-masked]>
Date: Thu, 21 Sep 2000 23:10:40 GMT

Hi Reiner,

>From: Reiner Ludwig <[email-masked]>
>To: "Al-hussein Abou-zeid" <[email-masked]>
>CC: [email-masked]
>Subject: Re: pilc minutes for IETF 48
>Date: Thu, 21 Sep 2000 23:33:10 +0200
>
>At 16:45 21.09.00 +0000, Al-hussein Abou-zeid wrote:
>If you have a reliable link layer protocol (ARQ) _and_ you tune the error
>>>recovery persistency of that protocol to a high value like 64 seconds
>>>(TCP's max. RTO), you pretty much eliminate losses but trade them for 
>>>delay.
>>
>>And, is this good/acceptable? How will this affect your TCP link? Also,
>>could you please give a pointer to where exactly in your thesis (since you
>>have referenced it in many previous e-mails) do you analyse this case?
>
>Sections 4.1.4 and 4.3.3. Which you can also read as a paper:
>http://iceberg.cs.berkeley.edu/papers/Ludwig-WINET99/

Your above mentioned paper states that "link layer error recovery over 
wireless links for reliable flows",  "based on a case study of the 
circuit-switched data channel imlementation in GSM" "yields an improvement 
of up to 25 percent when the channel quality is good and 18 percent even 
under poor radio conditions". "The improvement is accomplished by using a 
larger (fixed) link layer frame size". "These results highlight the 
importance of measurement-based analysis in wireless networks where protocol 
performance is highly dependent on the error characteristcis of the wirless 
channel".

which is surprisingly close in principle to my original e-mail,
>>Two comments; First, the performance of TCP is sensitive to the specific 
>>wireless medium characteristics, especially loss behavior
>>So, there are no magic TCP values that would work for any wireless
>>link. Second, what do you mean by a "right link layer". Is there such a 
>>thing? If you mean a wireless link that is as pure
>>as an optical link,  or even a twisted pair, then, this
>>it is probably a very special case of a wireless link.

Also, the paper you site has no mention of ARQ schemes or their tuning, 
which is the point of discussion!

Regards,

Hussein.

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.

---

From: Nitin H Vaidya <[email-masked]>
Date: Thu, 21 Sep 2000 21:04:53 -0500 (CDT)

>> far more changing, and will end acting more like a land line.

I agree that wireless link layers might do a lot of changing.
Not as confident that they will in the end look more like
a land line - hopefully, you are right, 

  >> or some combination of the two (e.g. ARQ for a while and then give up).

What I was refering to is
redundant UDP packets (e.g., one "check" packet for every 8
"data" packets), not redundancy "within" a UDP packet,
     (incidentally, there is an interesting issue here
     regarding the trade-offs between the ability to "correct"
     a packet loss using the redundancy, and the potential
     increase in loss rate due to increased congestion.)

  >> B<-->C as three independent cases.  IP multicast complicates that a little,

I do not understand what you are saying. Granted that the A--B
path will usually have multiple hops (which is what I was suggesting
by a long -------------- link as opposed to short ---- link -:)
But I do not get what you saying here.

  >> is certainly stretching the end-to-end principle and probably completely

Well, the feedback does not have to say that "link from B to C
lost packet P due to errors" - it is enough to feed back
that "packet P was lost due to errors. Would this violate the
end-to-end principle ?

Incidentally, would a "fully reliable link layer" conform
to the end-to-end principle ?

  >> wireless links are completely different from any kind of links that IP

Clearly, the fact that a link is wireless by itself makes
it no different from a wired links. The question I guess is whether
the designers will ever design a wireless link to look like
today's wireline links.

  >> an extreme example of the syndrome.

I will be happy to join in WAP-bashing ... I am not a fan of
WAP either (although I hear WAP 2.0, or whatever the number
is these days, is an improvement).

Enough said. I do not think I have much more to add to
what I have already said ... so I will shut up for a little
while.

Regards.

- nitin

---

From: Vernon Schryver <[email-masked]>
Date: Fri, 22 Sep 2000 10:04:44 -0600 (MDT)

> But I do not get what you saying here.

I'm saying that you must pick one of the three links, A--C, A--B, or B--C,
to talk about.  You shouldn't argue, as you seemed to, that what A and B
can do is relevant to what A and C can do.
Or in perhaps better words, you cannot assume that there is exactly one
dotted line "...." link in the path between A and C or even that the
number of dotted line links is constant.

> that "packet P was lost due to errors. Would this violate the

Depending on many things including what it means, I think the answer to
that is "probably but not necessarily."  The ends already know that "packet
P was lost due to errors" if they care--else TCP could not be a reliable
protocol.  The most that a link can affect is when the ends know.

> to the end-to-end principle ?

That's the wrong kind of question.  The only answer is "huh?"  My take on
the end-to-end principle is that the ends worry about everything related
to the overall application, while individual links are dumb and do no more
than make best efforts to get through packets their little parts of the
path.  Individual links are the tail of the dog.

Whenever you propose making even the slightest change in TCP, UDP, the
end hosts, or the applications to accomodate the special characteristics
of a link, whether it is a link with ~9600 bit/sec throughput, 80 or 300
millisecond delays, and suffers burst errors lasting 1-20 seconds or some
other kind, you are probably breaking the end to end principle and making
a serious design error.  (Anyone who thinks I'm trying to describe a
wireless link is wrong.  I'm describing something popular 12 years ago.)

> the designers will ever design a wireless link to look like

That's very interesting but not as interesting as the questions
 1. how do wireless links differ from other links used for IP
 2. has TCP been run or is it run over links similar to wireless links?

The standard wireless answers, "completely" and "never at all," are not
impressive.
The real answers to those two questions and the reasons many have never
heard of counterexamples to the standard wireless answers bear on the
question of how wireless links will change.  It wasn't that those old
links didn't work or that their principles of operation would not be
useful today.

---

From: Crocker Ron-QA1007 <[email-masked]>
Date: Fri, 22 Sep 2000 13:31:29 -0500

> -----Original Message-----

They're completely different. :) (Sorry, couldn't resist)

Wireless links (in a public network setting, like cellular) exhibit 3
characteristics counter to other links providing an IP:
	a) Slow (relative to other media - 9.6Kbps - 14.4Kbps typical,
though higher rates are coming)
	b) Noisy (bit error rates on the order of 10**-2 - 10**-4, 3 to 5
orders of magnitude worse than wires)
	c) Expensive (relative to PSTN/ISDN connections of equivalent
capability)

In exchange for these characteristics, you get the ability to move about
freely (so to speak), within certain boundaries, without being tethered to
some place. The "trick" in building cellular systems is to find a way to
balance those three characteristics to provide a cost-effective solution.

Wireless often implies [public] cellular radio, but that's not necessarily
accurate. 802.11 is wireless. I get pretty good service on it too, if I'm
close enough to the access point and not too many other people are around.
802.11 is DS spread spectrum, but it's not public in the same sense as
cellular. It's low power in an unlicensed band. It will compete with garage
door openers and cordless telephones as interference sources. Cable modems
are RF, but on wires. DOCSIS says that it's 64QAM; my interpretation (after
5 minutes of study, so I can likely be wrong) is that's to everyone all the
time. In a cellular system, that modulation is available in nominally 3% of
the cell.

>  2. has TCP been run or is it run over links similar to 

Yes, of course it has. IIRC, the problems with TCP have been related to
interactions between 1 particular characteristic above (noise), its
mediations (retransmissions on the link), and TCP characteristics.
> links didn't work or that their principles of operation would not be

["Didn't work" is, I'll claim, a matter of opinion. You probably wouldn't
run streaming video or voice over them, but you could (generally) do
SMTP/POP and HTTP services, even with CDPD. These services are TCP-based,
aren't they?]

Maybe I'm being particularly dense today, but I thought that was the charter
of this group, to define the principles of operations for these kinds of
links. That definition would be useful to both camps - the wireless guys and
the internet guys - to better understand both worlds.

Ron