Re: RE: AD request / L2 Triggers Chapter Statement

William Ivancic wrote:
>>
>> 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.

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.

...

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

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






_______________________________________________
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/