Re: RE: AD request / L2 Triggers Chapter Statement

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


>
> 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.
> <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.
>
> 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


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