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