Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard

From: Ihor Strutynskyj ([email protected])
Date: Tue Apr 07 1998 - 00:54:02 EDT


>Regards,
>
>Eric
>
>Note for the record:
>
>I don't think there is anyone seriously considering proposal of
>anything related to mixed-loss environments that:

Actually yes.

>
> 1) attempts to signal the experiencing of *individual* errors
> experienced
>
> or
>
> 2) attempting to infer corruption versus congestion from loss
> patterns.

Above two kinds of losses can be handled by the source if
explicit information about losses is available for the source.
This can be SACK blocks with Explicit Loss Notification bit
set in the TCP header. ELN bit can be easily set by base station
looking at all seen packets and comparing the numbers with losses.
The modification of TCP header by BS is impossible in case of
secure/encripted communication. In this case ICMP may help,
or move the bit up to IP header. This scheme can live also with link
FEC.
-Ihor.
>
>These are (in my opinion) simply unworkable.
>
>What CAN be detected (and signaled) are delimited *periods* of
>link difficulties. This can be a link-outage (i.e., you've lost
>a link-lock, are hunting in the noise to resync after a deep
>enough fade, had a hand-off, etc.) or detection of a significant
>fade on the channel. FEC may get you a pristine channel in some
>environments if you can pay the appropriate price - but that price
>can also mean that you lose access to the channel for periods of time.
>
>The detection and recovery of link problems *is* in the realm of the
>link protocol, but unless you get a clue to the transport protocol's
>state-machinery, you run the risk of triggering false congestion
>responses. These congestion-responses will impose further (unnecessary)
>performance degradation during periods when the path bottleneck is not
>congested.
>
>Making the extra information on link (un)availability to the transport
>protocol *can* improve things.
>
>This does not "burden TCP" with link layer problems, it merely allows
>the signaling of additional advisory information about the network to
>the transport protocol.
>
>It wasn't my desire to rehash the noisy link debate here.
>
>
>



This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:42 EST