Subject: Re: [pilc] RE: AD request / L2 Triggers Chapter Statement

From: Joe Touch <[email-masked]>
Date: Thu, 06 Jun 2002 14:44:41 -0700

Phil Neumiller wrote:
>>>Right, but many routing systems are built ON IP and below transport.
>>>Take MIP, any MANET protocol, ICMP itself, OSPF, BGP4, etc.  All of
>>>these systems that reside at the IP layer in routers CAN INDEED make
>>>extremely good use of this information.
>>
>>Which of these operates on millisecond decisions?
> 
> 
> Oh, this is a trick question....  NONE because they CAN'T.  YOU can NOT
> convince me that they WOULD NOT if they COULD!!!!

OK - so we agree to disagree on whether anyone would use this 
information.  My concern is that no existing protocol does anything 
anywhere near this fast in the Internet; the simple variability in paths 
is enough to kill most 'hard realtime' guarantees on timing. As a 
result, it isn't clear that they COULD (perhaps not enough to convince 
you, but can you convince me??).

>>What I'm asserting is:
>>
>>if it's within two links of the same type, a meta-link can do it
> 
> 
> Yeah, and where is this defined in ANY commercial IP stack???

No. And rightly so. That would be inside the link layer.

>>if it's between two different links, IP routing has to do it,
>>and that doesn't care about millisecond events
> 
> Baloney!  Policy based routing most certainly does. 

Can you be more specific (and less inflammatory, please?)?
E.g., a policy based-routing that would _change_ what it does on a 
millisecond timescale. Granted that policy routing operates on those 
timescales, but it isn't clear that anything it does would change on 
those timescales.

> Especially with respect to
> wireless handovers which is the MAIN purpose of this discussion.

Wireless handovers is a link-layer issue, not necessarily an IP-layer issue.

>>Again, if you want to do this on a single box, you don't need an L2 
>>trigger. It's not that you're talking to IP in general, but that you're 
>>talking to a particular stack implementation.
> 
> Wrong.  We absolutely NEED IP to change so that there is a standard 
> mechanism for ALL future L2s to communicate with IP from the bottom up.

So what you're saying is:

	- we NEED L2 triggers

	- we NEED all of IP to change to be realtime to USE L2 triggers

	- everyone NEEDS all of this to support one link type for
	certain applications

Sounds a lot like optimizations.

> Imagine yourself as an L2.  How on earth are you going to send any kind
> of link quality assesment to IP? 

Better - _why_ am I sending link quality assessment to IP? What would IP 
do differently? The routing protocol already sends route advertisements; 
they get there or they do not; if they do not, the routing changes (on 
the timescales of seconds).

IP is not a realtime system. You're asserting it should be; that sounds 
like a job larger than a single WG can handle.

---

Does anyone else have a position to share on this?? I'm not claiming 
that this group should not move forward; it would be better, IMO, if 
there were a clearer reason, however...

Joe

_______________________________________________
pilc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pilc
http://www.ietf.org/html.charters/pilc-charter.html
http://pilc.grc.nasa.gov/

---

From: Joe Touch <[email-masked]>
Date: Thu, 06 Jun 2002 11:37:47 -0700

Phil Neumiller wrote:
>>The whole of L2 Triggers assumes that:
>>
>>1) events occur at the link on the timescale of milliseconds
>>2) these events must be communicated to L3
>>3) L3 can do something useful with these triggers
>>
>>#1 is granteed, but #2 assumes that #3 ever occurs. There is little in 
>>IP as a whole that supports such "realtime" requirements of millisecond 
>>responses. In fact, that's in opposition to most of the rest of the 
>>Internet architecture.
> 
> 
> Yes.  That IS the point.  There needs to be. 

But there isn't; IP currently won't do anything interesting with info on 
that timescale. It's like calling up someone who won't answer.

> If IP were to create a nice
> home for L2s, life would be much simpler for wireless system providers.
> Wireless links stink.  They come and they go.  IP was build for 10E0-06 
> or better BER links.  This needs to change.

Yes - but, as I suggested later on, it can change by creating a wireless 
virtual link that goes over different wireless physical links, ala ATM. 
It need not involve IP.

> It needs to change in IP not
> in the L2s.  The L2s do what they can.  I would beg to differ that this
> is NOT realtime.  Many routers handle millions of packets per second
> over optical links.  THIS IS VERY REALTIME.

Nothing about IP requires that packets be routed in microseconds. The 
RATE of routing is fast, but the latency need not be so low.

Further, we're talking about updating routing, which is much slower in 
general.

>   Applications include but are not limited to:
> 
> o      Fault tolerant failover of links

Usually within a single link layer type - i.e., from one 300Mhz wireless 
link to another 300Mhz wireless link. That's what I mean as "intra link" 
- the link layer could have handled that.

> o      L2 signal quality indications

To what end? What would IP do differently?

> o      L2 congestion control

Again, to what end? IP doesn't have congestion control; TCP doesn't 
react on milliseconds.

> o      L2 fragmentation control

There's an existing mechanism for that - MTU. Does it change on the link 
on the fly?

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 06 Jun 2002 13:05:28 -0700

> This is where you are completely missing it.  The whole point is for routers
> with several heterogeneous wireless links to policy route over them in the
> event of failure.  I think you are thinking in terms of a simple host.  Think in
> terms of what a MANET or router gains from this.

What I'm asserting is:

> It would most likely simply convey this to the transport layers that have
> registered interest.  It may do this with an ICMP message.

Name a transport layer that reacts on millisecond timescales.

> TCP DOES react in milliseconds on the boxes (routers) and hosts I work
> on.  It will get even faster as time goes on.

TCP reacts on RTTs, usually multiple RTTs. Even then, what would TCP do 
that it doesn't already to? I.e., you don't need an L2 trigger to 
program a box to send TCP ECN data back.

> In many instances it would be very NICE to have the option.  QoS queueing
> mechanisms can benefit greatly from such capabilities.

Joe

---

From: "Carl Williams" <[email-masked]>
Date: Thu, 6 Jun 2002 14:30:02 -0700

Hi Behcet,

   I have not had time to read your charter.

   However, when I lead the pre-BOF meeting in Minn
   we used the above proposed charter.

Carl

----- Original Message -----
From: "Behcet Sarikaya" <[email-masked]>
To: "Phil Neumiller" <[email-masked]>; "Joe Touch"
<[email-masked]>
Cc: <[email-masked]>; "Behcet Sarikaya" <[email-masked]>;
"Scott Corson" <[email-masked]>; "Eric Whitehill"
<[email-masked]>; <[email-masked]>;
<[email-masked]>; "Rex Buddenberg" <[email-masked]>;
<[email-masked]>; "Dr. Chane L. Fullmer" <[email-masked]>;
<[email-masked]>; "'William Ivancic'" <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; "Anders Lindgren" <[email-masked]>;
<[email-masked]>; <[email-masked]>; "Armando L. Caro Jr."
<[email-masked]>; <[email-masked]>
Sent: Thursday, June 06, 2002 1:50 PM
Subject: Re: [pilc] RE: AD request / L2 Triggers Chapter Statement

> Folks,
>   Thanks Joe for starting a good discussion on the
> Charter (not Chapter) statement that I had posted.
>   I had left the chairs open and so far no volunteers
> appeared to lead this activity. I approached some
> people but they did not seem to be interested in.
>   If anyone interested in leading please come forward
> so that some action can be put forward for IETF 54 or
> IETF 55.
>   Regards,
> --- Phil Neumiller <[email-masked]>
> wrote:
> > wireless handovers which is the MAIN purpose of this
> > discussion.  When users
> > are paying for mobile services they expect SERVICE.
> >
> > You are missing the point.  Most of us are talking
> > about wireless systems and the
> > L2 being able to convey its highly variable state to
> > stacks that CAN react to
> > it.
> >
> > of link quality assesment to IP?  THERE IS NO
> > STANDARD MECHANISM
> > CURRENTLY.  That is the reason we need the BOF, WG,
> > and the standard
> > track RFC for specifying the underspecified IP
> > underbelly.  The PILC WG has
> > taken an Ivory tower position and said all kinds of
> > things about what L2s
> > should and should not do.  I am representing L2s and
> > pushing back on what
> > I believe IP needs to do!!!  Its silly for the PILC
> > group to come up with all kinds
> > of recommendations for standards they can't control
> > when they CAN control
> > the safe harber that IP can provide for wireless and
> > other L2s.
> >
> > -Phil Neumiller
> >
> >
> >
> --behcet
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! - Official partner of 2002 FIFA World Cup
> http://fifaworldcup.yahoo.com
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 6 Jun 2002 13:50:02 -0700 (PDT)

Folks,
--behcet

---

From: Joe Touch <[email-masked]>
Date: Thu, 06 Jun 2002 11:22:09 -0700

Behcet Sarikaya wrote:
> Hi Scott,
>   I am attaching something that can be used to the
> effect of a charter.
>   Any comments?

Hi, all,

I haven't seen much discussion on this, so I'll start with a few questions:

> ------------------------------------------------------------------------
> 
> L2 Triggers BOF (l2tr)
> 
> July 2002
> ================================
> 
....
> 
> The ability to quickly and efficiently determine the existence (or
> non-existence) of a link is needed most commonly as a consequence of
> movement-induced changes in network topology. Mobile handoff, whether
> in cellular or WLAN contexts, generally requires that the entire
> process complete within 10's of milliseconds is seamless voice
> service is to be maintained. This requires very fast detection of
> changes in link status. Since a link layer best knows its current
> link status it is natural to use L2 triggers for
> this purpose.

I would suggest that a link that has such events is in fact a link built 
on links, e.g., a virtual link layer. There have been others - Sonet, 
ATM, etc., that have had similar millisecond (or faster) handoff 
mechanisms. There may be value in standardizing that sort of link 
facility in general, but can anyone clarify why it is useful to hand 
such urgent information to a layer that is otherwise non-urgent in nature?

I.e., specifically:

	A) justify millisecond event communication to a non-realtime
	layer-3 (what specifically will IP do?)

	B) (alternately) justify that this is not an intralink layer
	(e.g., is it inter-link, between two different links?
	will any one link ever need to tell any other link layer?)

Joe

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Thu, 6 Jun 2002 16:47:29 -0700

> will any one link ever need to tell any other link layer?)

Hi Joe,

We have been working on link-layer triggers for a while.
The work, which later led me to suggest this bof, was
originally driven by the fast handovers for mobile IP
work we have been doing in Mobile IP WG.

http://www.ietf.org/internet-drafts/draft-ietf-mobileip-fast-mipv6-04.txt
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-lowlatency-handoffs-
v4-04.txt
(this somehow expired...)

And if you look at our draft draft-manyfolks-l2-mobilereq-01.txt,
I think it'll answer some of your above questions:

http://yegin.org/ietf/draft-manyfolks-l2-mobilereq-01.txt
(this had expired as well, we'll be updating it)

alper

---

From: "Phil Neumiller" <[email-masked]>
Date: Thu, 6 Jun 2002 14:47:58 -0400

> that timescale. It's like calling up someone who won't answer.

This can be throttled back and discovered.  Hosts with slow time constants
can make this know to the L2 via the API (underbelly interface).  The L2
can querry the IP layer and find out how fast it can accept events.

> virtual link that goes over different wireless physical links, ala ATM. 

This is not practical for routing systems.  This is what SCTP multi-homing
can do for you or other TRANSPORT layer QoS mechanisms such as 
RSVP.  Policy based routing requires this AT the IP layer.

---

From: "Phil Neumiller" <[email-masked]>
Date: Thu, 6 Jun 2002 16:33:23 -0400

> and that doesn't care about millisecond events

Baloney!  Policy based routing most certainly does.  Especially with respect to
wireless handovers which is the MAIN purpose of this discussion.  When users
are paying for mobile services they expect SERVICE.

> program a box to send TCP ECN data back.

You are missing the point.  Most of us are talking about wireless systems and the
L2 being able to convey its highly variable state to stacks that CAN react to
it.

Wrong.  We absolutely NEED IP to change so that there is a standard 
mechanism for ALL future L2s to communicate with IP from the bottom up.
Imagine yourself as an L2.  How on earth are you going to send any kind
of link quality assesment to IP?  THERE IS NO STANDARD MECHANISM
CURRENTLY.  That is the reason we need the BOF, WG, and the standard
track RFC for specifying the underspecified IP underbelly.  The PILC WG has
taken an Ivory tower position and said all kinds of things about what L2s
should and should not do.  I am representing L2s and pushing back on what
I believe IP needs to do!!!  Its silly for the PILC group to come up with all kinds
of recommendations for standards they can't control when they CAN control
the safe harber that IP can provide for wireless and other L2s.

-Phil Neumiller

---

From: "Phil Neumiller" <[email-masked]>
Date: Thu, 6 Jun 2002 14:30:56 -0400

> responses. In fact, that's in opposition to most of the rest of the 

Yes.  That IS the point.  There needs to be.  If IP were to create a nice
home for L2s, life would be much simpler for wireless system providers.
Wireless links stink.  They come and they go.  IP was build for 10E0-06 
or better BER links.  This needs to change.  It needs to change in IP not
in the L2s.  The L2s do what they can.  I would beg to differ that this
is NOT realtime.  Many routers handle millions of packets per second
over optical links.  THIS IS VERY REALTIME.  The underbelly of
IP is underspecified and must provide a robust well documented 
interface for L2 attachement.  This includes notifications from L2s.
Just think of it is another sockets layer but on the bottom side of IP.
Also, many of these events will need to be relayed to the various
transport protocols that have registered interest in the events for the
particular link.  Applications include but are not limited to:

Thanks,

Phil

---

From: "Phil Neumiller" <[email-masked]>
Date: Fri, 7 Jun 2002 09:05:05 -0400

Hi Joe,

Sorry about the militancy.   As you can tell, I am a strong advocate of L2 triggers.  I have
been working in wireless for many years and this IS one of the REALLY important missing links
IMHO (excuse the pun).

I had this in mind when I founded (some would say confounded :-) the SeaMoby WG.  This
topic however never made it to the SeaMoby charter.  What I want to see now, is a WG whose
sole purpose in life is to specify an interface to the underside of the IP stack.  This has remained
an implementation specific black art heretofore as you can bear witness.  

I have responded to the rest of your comments below in a more RELAXED manner... :-)

Before I do that, I want to state that many new 3G/4G/MANET type of devices have pretty
beefy real time OS's and can communicate across many simultaneous links that come and go
on milisecond time scales.  Although your virtual link sounds like a nice idea I would recommend
that you carefully study SCTP multi-homing because it can do this already and is an RFC.

onward...

----- Original Message ----- 
From: "Joe Touch" <[email-masked]>

> you, but can you convince me??).

There are two cases here that are of utmost importance.

1).  The edge device managing multiple 10E0-02 links and attempting to
       multi-home across them and handover seamlessly.  Dropping packets
       (specifically VOIP and or other codec packets) is usually a bad thing.
       In break-before-make L2 systems it is often necessary to drop some
       at the handover seams.  For this reason, it is often necessary to assess
       link quality statistically at higher layers to make informed decisions about
       initiating handover processing.  There is tons of latency involved in
      handovers and registrations and security associations.  Any "heads 
      up" from the link layer is extremely helpful.  Let's face it.  IP was not
      originally conceived for handoffs.  IP is an evolving creature.  The world
      is going mobile and IP must too.

2).  Routers that have several heterogeneous or homogeneous wireless links
       also need to collect link statististics to ensure quality of service.       

> No. And rightly so. That would be inside the link layer.

How exactly would these two link layers talk to each other?  Each would have
its own IP address right?

> timescales, but it isn't clear that anything it does would change on 

The argument is circuitous.  What we are saying here is that the is a NEED
to do this for seamless handover.  We are not sayint that anything does this 
now.  If you are happy with MANET, and MIP handovers as they stand, then
we can all go home.  If you feel that there is something lacking with respect
to link knowledge being propagated upward to IP and transport then we
have work to do here.

> Wireless handovers is a link-layer issue, not necessarily an IP-layer

IP over everything.  Dumb network, smart host.  What you are suggesting
is an IP architecture violation.

Handover decisions need to be above the IP layer so that routing can be involved.
How on earth would mobileip and MANET cooperate if the link layer handled the
handovers and there was absolutely no standard way to communicate this to the
IP layer.  You are starting to make my arguments for me Joe!

> So what you're saying is:

We need a mechanism and interface proviced by IP to allow any and all future L2s to
use a STANDARD IP triggering notification method.

> - we NEED all of IP to change to be realtime to USE L2 triggers

Hmm.  This seems a bit sarcastic to me but I will go with it.  No.  We need an input
queue (can be implementation dependent) on the underside of IP that can accept
events that occur on millisecond time scales.  These events can be forwarded to 
routing modules and transport modules that have registered interest in these events.
What do you mean by "all of IP"?  I would agree that I suggest IPv6 do this for
certain.

> - everyone NEEDS all of this to support one link type for

No.  The beauty is we do this once and every L2 from here to eternity works
seamlessly.  You have it completely backwards.

> Sounds a lot like optimizations.

Yes to the design of the underspecified IP underbelly.  No harm in standardizing
optimizations last time I checked.

> there were a clearer reason, however...

Most anyone with experience implementing LLCs, MACs, and interfacing
them to the IP layer clearly sees the need for this work.  In fact all those people
that are CC'd on this EMAIL have expressed interest in precisely this.  That is the
definition of a BOF.  You may just be a different kind of bird!  :-)

Thanks,

Phil (IP underbelly standardization advocate)

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 7 Jun 2002 08:13:36 -0700 (PDT)

Folks,
  Please find attached l2 Tragiggers Charter
statement, revised as per the comments received.

  What are the next steps?

Regards,

--behcet

L2 Triggers BOF L2TG (L2 TriGgers)

July 2002

CHAIRS: Phil Neumiller <[email-masked]>
        Behcet Sarikaya <[email-masked]>
        Carl Williams  <[email-masked]>; 

o DESCRIPTION OF THE BOF:
  =======================

The purpose of L2 Triggers work is to develop layer 2
service specifications for wireless links.  Service
interactions between the IP layer and the link layer
will be identified and defined precisely. The work may
involve the definition of a protocol to carry the
interaction occurring at layer 2 entities to where L3
interface exists. The work will concentrate on the
definition of service interactions from layer 2
towards layer 3, aka triggers.

The ability to quickly and efficiently determine the
existence (or non-existence) of a link is needed most
commonly as a consequence of 
movement-induced changes in network topology.  Mobile
handoff, 
whether in cellular or WLAN contexts, generally
requires that the 
entire process complete within 10's of milliseconds is
seamless 
if packet-based services are to be maintained.  This
requires very fast 
detection of changes in link status.  Since a link
layer best 
knows its current link status it is natural to use L2
triggers for this purpose.

While the link status for L3 handover protocols is
expected to be the most popular use of L2 triggers,
there are other areas or protocols that may benefit
from L2 events to be triggered to layer 3, e.g. IP
Paging protocol. 

The work will concentrate on identifying the triggers
needed by IP layer such as the link status. For each
trigger it is necessary to identify the parameters to
be passed. It is also important to identify the best
formalism to define these parameters. The use of API
languages such as C, Java will be considered. Another
aspect of formalism is whether or not callbacks should
be used or is it preferable to define the triggers in
the form of operating system primitives.

The technical problems to be solved include:

 -  generic triggers and triggers specific to
different layer 3 protocols such as handover, paging,
MANET routing, etc.
-  L2 trigger transport protocol.
-  Triggers specific to each link such as cellular,
802.11, HIPERLAN1, HYPERLAN2, Bluetooth, future
technologies such as Flash OFDM.

 -  The work may optionally extend to the coordination
for the definition of Layer 2 trigger transport
protocol for the links that do not support it with
IEEE, Bluetooth, PPs and other organizations. L2
trigger transport protocol must use IP transport and
may be version dependent.

The work on L2 triggers needs some amount of
collaboration and synchronization with MobileIP WG and
MANET WG and IP Paging BOF.

o The BOF's goals are:
  ===================

- Show why L2 triggers need to be defined.

- Assess interest in forming a Working Group on L2
triggers.

- Get feedback on the problem statement, which could
be used as the
  basis for a Working Group Charter. The discussion of
the problem
  statement on the mailing list is recommended prior
to the BOF. The BOF
  will be used to form a working group.

- Reach consensus on the terminology to be used for L2
triggers.
  A discussion on terminology on the mailing list is
recommended to  
  speed up the process of reaching consensus.

- Outline a number of requirements that must or should
be met by the
  solutions for supporting a L2 trigger transport
protocol. 

- Come up with an architecture document for L2 trigger
transport protocol.  

- Outline any security issues.  

o L2TR BOF AGENDA (54th IETF Yokohama)
  ========================================

- Introduction and agenda bashing 5 min

- TBD
  
- General discussion and opinions on moving forward -
All 20 min

o DELIVERABLES
  ============

- Terminology, Problem Statement (e.g.
draft-corson-triggered-00.txt): July 02

- L2 Trigger APIs : during 03
- Requirements and Framework: December 02

- L2 Trigger Transport Protocols : during 03

o MAILING LIST:
  =============

  [email-masked]

  Subscription instructions can be found at ietf.org.

---

From: William Ivancic <[email-masked]>
Date: Fri, 07 Jun 2002 04:36:03 -0400

>
>Does anyone else have a position to share on this?? I'm not claiming that 
>this group should not move forward; it would be better, IMO, if there were 
>a clearer reason, however...
>
>Joe
>

I think L2 triggers will be useful.

How fast these something needs to react to these triggers is a matter of 
implementation, and if this is a hardware reaction or a protocol reaction.

I think there may be a semantics problems in the use of IP in Joe and 
Phil's discussion.  Perhaps there isn't as much separation thought as 
appear in the discussion.

Example 1:

I've been working with mobile-ipv4 and mobile router technology on a joint 
effort between NASA and Cisco.  Cisco has implemented a preferred path 
option in the  MR in which if an interface is UP and it is higher priority, 
that path will be taken.  Without a layer-2 trigger, the router cannot 
determine how "good" the particular wireless link is.  If the preferred 
path is bad, but still good enough to pass some data, registrations will 
occur and that path will be tried even though it may be oscillating up and 
down.  Thus, we implemented a "hold-down timer" into the system that 
implies an interface has to be UP for a certain period of time before it is 
considered stable.   This is a manual setting, however.  Using a layer-2 
trigger would be much preferred.

So is this an IP solution or a solution related to Internet technologies 
that would definitely aid in the performance of IP protocols?

Does this reside in the IETF or elsewhere?   Perhaps it belongs in the IEEE 
and/or Telecommunication Industry Association (TIA) as it appears to be 
hardware/firmware interaction with router hardware/firmware.  This 
interaction most likely doesn't require a Internet Protocol (I say that, 
because one may argue that all controlled interactions require a "protocol".)

Example 2:

NASA funded BBN to investigate Explicate Error Transport Notification
http://roland.grc.nasa.gov/~mallman/papers/TR8333.ps

Rajesh Krishnan, Mark Allman, Craig Partridge, James P.G. Sterbenz. 
Explicit Transport Error Notification (ETEN) for Error-Prone Wireless and 
Satellite Networks. Technical Report No. 8333, BBN Technologies, March 2002.

It would be very useful for TCP to be able to determine if packets were 
lost due to errors rather than congestion - or at least that some 
percentage were lost due to errors.  If this were possible, TCP may be able 
to perform better over moderately congested error-prone paths.   Having 
layer-2 mechanisms available that would indicated rf-link status, such as 
link quality, packet loss, etc... may help TCP's performance.  Here, time 
periods of 50 millisecond plus are probably sufficient.  For very low delay 
links, TCP windows are small and reaction time fast enough such that 
layer-2 triggers may to not provide a tremendous amount of benefit.

This appears to be a problem that justifiable resides within the IETF as we 
are talking of protocols and performance.

Will

---

From: "Phil Neumiller" <[email-masked]>
Date: Fri, 7 Jun 2002 16:51:34 -0400

Hi Will,

The IETF has not cleaned its own house with respect to the first example.  Finger pointing
at L2s will get us nowhere fast.  It is time for the IETF to "provide a method" for L2s to use
to communicate *to* the IP stack and above it.  Once the IETF has done all it can do with
respect to this, then I believe it is justified to point fingers at L2s.  So far the IETF attitude is
that  IP is perfect, go fix your L2, or its implementation specific.  That does not fly anymore,
especially with wireless devices which are proliferating faster than any other type of L2.  They
will also be more ubiquitous than any other type in time as well.  Wireless L2s just aren't
going to get much better any time soon.  There are physics limitations that don't hold for
wired or optical connection.  IP must support mobility inherently for the Internet to grow to
the next stage.  Mobility must be designed into the IP protocol.  The place to start is from
the perspective of wireless L2s looking UP at the IP stack.

Thanks for your insight.

-Phil

----- Original Message -----
From: "William Ivancic" <[email-masked]>
To: "Joe Touch" <[email-masked]>; "Phil Neumiller" <[email-masked]>
Cc: "Behcet Sarikaya" <[email-masked]>; "Scott Corson" <[email-masked]>; "Eric Whitehill" <[email-masked]>;
<[email-masked]>; <[email-masked]>; "Rex Buddenberg" <[email-masked]>; <[email-masked]>; "Dr.
Chane L. Fullmer" <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; "Anders Lindgren" <[email-masked]>; <[email-masked]>; <[email-masked]>;
"Armando L. Caro Jr." <[email-masked]>; <[email-masked]>
Sent: Friday, June 07, 2002 4:36 AM
Subject: Re: [pilc] RE: AD request / L2 Triggers Chapter Statement

> I've been working with mobile-ipv4 and mobile router technology on a
> joint effort between NASA and Cisco.  Cisco has implemented a preferred
> path option in the  MR in which if an interface is UP and it is higher
> priority, that path will be taken.  Without a layer-2 trigger, the
> router cannot determine how "good" the particular wireless link is.  If
> the preferred path is bad, but still good enough to pass some data,
> registrations will occur and that path will be tried even though it may
> be oscillating up and down.  Thus, we implemented a "hold-down timer"
> into the system that implies an interface has to be UP for a certain
> period of time before it is considered stable.   This is a manual
> setting, however.  Using a layer-2 trigger would be much preferred.
>
> Does this reside in the IETF or elsewhere?   Perhaps it belongs in the
> IEEE and/or Telecommunication Industry Association (TIA) as it appears
> to be hardware/firmware interaction with router hardware/firmware.  This
> http://roland.grc.nasa.gov/~mallman/papers/TR8333.
> <http://roland.grc.nasa.gov/~mallman/papers/TR8333.ps>  ps
> <http://roland.grc.nasa.gov/~mallman/papers/TR8333.ps>
>
> Explicit Transport Error Notification (ETEN) for Error-Prone Wireless
> and Satellite Networks. Technical Report No. 8333, BBN Technologies,
> March 2002.
>
> percentage were lost due to errors.  If this were possible, TCP may be
> able to perform better over moderately congested error-prone paths.
> Having layer-2 mechanisms available that would indicated rf-link status,
> such as link quality, packet loss, etc... may help TCP's performance.
> Here, time periods of 50 millisecond plus are probably sufficient.  For
> very low delay links, TCP windows are small and reaction time fast
> enough such that layer-2 triggers may to not provide a tremendous amount
> of benefit.
>
> This appears to be a problem that justifiable resides within the IETF as
> we are talking of protocols and performance.
>
>
> Will

---

From: Joe Touch <[email-masked]>
Date: Mon, 10 Jun 2002 09:52:41 -0700

Phil Neumiller wrote:
...
> that you carefully study SCTP multi-homing because it can do this already and is an RFC.

SCTP, though an RFC, is not (IMO) the best solution here. We implemented 
a system that did dynamic failover using existing standard RFCs several 
years ago:

"Dynamic Host Routing for Production Use of Developmental Networks"
J. Touch and T. Faber, Proc. ICNP '97, Atlanta, Oct. 1997, pp. 285-292.
http://www.isi.edu/touch/pubs/icnp97/icnp97.ps

SCTP embeds too much of these standards inside the transport protocol 
(you might want to review the mail archives of their WG; you'll find my 
posts on this topic there).

>        (specifically VOIP and or other codec packets) is usually a bad thing.

IP is predicated on the fact that dropping packets is just fine.

If this is related to handoff between two links in the same technology, 
it is an intra-link (e.g., inside ATM, as an analogy) issue.

 >  IP was not
>       originally conceived for handoffs. 

Agreed.

 > IP is an evolving creature.  The world

Again, as others have pointed out, this requires a revision of the 
entire Internet architecture. Starting here isn't going to help; the 
result will be triggers to a non-existent (and un-contemplated) 
internet-wide facility.

>        also need to collect link statististics to ensure quality of service.       

Stats can be gathered by posting info in SNMP databases.

> its own IP address right?

In this case, it may be useful to revisit that decision. If the links 
are acting as backups, either they share an IP address (and the link 
layer determines which is active), or there is an IP layer above them 
(tunneled).

> to link knowledge being propagated upward to IP and transport then we

I agree that this is a circular argument. The problem is that the rest 
of the circle is large and unaddressed. There's insufficient 
justification to deal with this small arc of the circle to 'trigger' 
fixing the entire rest.

> is an IP architecture violation.

IP _OVER_ everything, not under or inside everything. You want 
in-network state (otherwise there wouldn't be handovers); which means, 
de-facto, you don't want IP for this layer.

> IP layer. 

No - _why_ would mobileIP and MANET need to cooperate? You haven't made 
that point yer.

> events that occur on millisecond time scales.

To send to _what_? Again, nothing in IP will react to things on these 
timescales. If it's on the _underside_, you can't know what it's going to...

> seamlessly.  You have it completely backwards.

You're still thinking about the link layer; try thinking about the 
routing protocols, the transport protocols, and the applications - THEY 
are the ones who will suddently have to care about events on millisecond 
timescales (they don't now). And, if the signal is on the underside of 
IP, unless they ALL do, you can't assume ANY do.

> optimizations last time I checked.

The IETF as a rule doesn't do this. Optimizations are "informational" at 
best.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 10 Jun 2002 10:35:29 -0700

> setting, however.  Using a layer-2 trigger would be much preferred.

L2 trigger, or SNMP database? Lots of what needs to happen in these 
cases isn't really a protocol issue; it's an application issue. 
Hold-down timer configuration isn't part of an interface API that's 
spec'd by the IETF.

...

> <http://roland.grc.nasa.gov/~mallman/papers/TR8333.ps>ps
> 
> <http://roland.grc.nasa.gov/~mallman/papers/TR8333.ps>Rajesh Krishnan, 
> Mark Allman, Craig Partridge, James P.G. Sterbenz. /_Explicit Transport 
> Error Notification (ETEN) for Error-Prone Wireless and Satellite 
> Networks_/. Technical Report No. 8333, BBN Technologies, March 2002.
> 

Except that lost packets are that - lost. Which TCP connection do they 
belong to? Are they TCP? Are they link retransmissions? If they're lost, 
they're lost.

Compensation for loss due to errors may be best done at the link layer, 
via adjustable FEC. It's not that you want TCP to _do_ anything 
different, it's that you want it NOT to backoff in these cases.

Joe