Hi. Sorry to be weighing in so late on this thread,
but there's been some mention of SCPS-TP and some of
the stuff that we've done. Here's a bit of what I
hope is clarification and elaboration.
>At 8:45 AM -0400 10/7/97, Mark Allman wrote:
>>dropped (congestion or corruption). Personally, I remain
>>unconvinced this will work well (it can never completely work; who
>>does a machine tell when it receives a corrupted packet? it can
>>never be sure the right host is being told, as the packet is
>>corrupt).
Well, not quite. There are ways to do such a thing. Here's
some discussion of what we have done:
>From our perspective, it's the rare case where one can reliably
correlate between individual losses on a link to a specific
traffic stream. What you can do, however, is detect loss-trends
on the link and signal those. This provides some extra information
that might be exploitable for network endpoints traversing this
link.
So, there are three things going on:
a. detection of a loss trend (link-layer)
b. signaling of potentially corrupt link (network/ICMP)
c. reacting to corruption signaling (transport)
Detection of loss trends:
Interfaces maintain some soft-state information regarding the
number of corruption events experienced within some window of
time; When the number of events exceeds a certain threshold,
the interface (and hence the link) is declared to be corrupt.
Obviously, you only want to do this for potentially lossy media
(say, RF); We've done this, and it worked fine.
Note that when the link goes down due to a link outage, one
can use the same mechanism as in (b) to send indications of
that, allowing TCPs to go into persist mode and probe/attempt
to reroute.
When you have a network entity that might also be the sink
of traffic (rather than just routing), you can configure
the interface to pass up corrupted packets, with a flag
indicating that they're bad. IP's header checksum can then
be used to verify that the address information is still valid.
(The probability that a 20-octet IP header is affected by an
undetected bit-error is less than 1 in 10**7 for a bit error
rate of 1E-3, assuming errors distributed according to a
Bernoulli process.) This information can then be exploited
locally (see signaling of corruption below).
Signaling of corruption:
When a link has been declared corrupt, the network layer
is responsible for notification to "recent users" of the
link. These "recent users" are logged in a LRU queue (similar
to that maintained by VJ Header Compression [RFC-1144]);
This queue size should be quite small, as corruption events
are likely to be short. Specifics are dependent on the usage
and coding characteristics of a particular link.
When a corruption even is declared, a "corruption experienced"
message is sent (an unreliable ICMP message) is sent to hosts
occupying the queue that are on the near-side of the corrupt
link - these hosts will notify their peers as part of the
transport traffic stream. As new hosts replace incumbent queue
members, a notification message will be sent if the link is
still declared corrupt. The rate of individual notifications
should be throttled (just as one would with source-quench
notifications).
If the *network* protocol header has an available bit for
signaling corruption, this bit could be set for each packet
sent or received on the interface during a corruption event.
For entities which are also hosting a source/sink of traffic
on this interface, the notification operation can short-circuit
the ICMP processing and directly flag appropriate transport
connections (set a corruption experienced flag in the TCB).
We opted to go with an ICMP-based signaling mechanism for
signals generated in mid-route because we have to deal with
the possibility that the IP payloads may be encrypted. This
is a reality in some environments, and may be something
that is applicable to a mobile/wireless environment as well.
Once the signal gets to one of the hosts, we use a TCP option
to signal the other side.
Reaction to corruption notification (forward path):
Upon reception of a corruption notification, all relevant
transport connections are marked as being in a corruption
experienced state. This state will last for a specific
period of time (flushed by either the expiration of a timer);
During this period, all transport segments acknowledging new
data (as well as duplicate ACKs) will include a Corruption
Experienced Option to signal to the far side of the connection
its corrupted state.
Reaction to corruption experienced option:
While incoming transport segments include the Corruption
Experienced option, losses will be treated as corruption
based loses. If an explicit congestion notification arrives
the sending rate should be reduced (via halving of cwnd)
This scheme requires no extreme layering violations - extra
information is provided to the transport protocol by the link
or network layers (and no layering violations at all outside
of the end-systems);
This approach is different than schemes, such as the Berkeley
efforts, that use transport-aware link protocols. The motivation
for our not adopting a similar approach is that we are not able
to assume that intermediate systems (link endpoints) will be able
to examine any headers beyond the network headers.
This is only mentioned here because someone always asks why. :o)
>>I may be wrong, it is a research area at best. In the
>>absence of such a mechanism, we must choose conservativly and
>>therefore take the drop as congestion and backoff.
>
>I hear from the IPv6 folk that the latest protocol spec's talk of
>the routers setting a congestion bit. If that were done, and if
>everybody were to speak IPv6 (let's not hold our breath) TCP would
>be able to tell the difference between a packet dropped because of
>congestion and one lost to corruption.
Actually, in an environment that involves a geostationary satellite
hop, the existing mechanism for signaling congestion, Source Quench,
provides some added advantage over a bit in the header. If the congested
site is on the "near" side of the satellite hop, the source quench message
will arrive much sooner than if a congestion bit is required to propagate
to the destination and then be fed back (you get both satellite hops in
that case). The problem with source quench in the past has been when
to send them. Cisco sends source quenches, but not more than once per
second, which seems OK. With RED, one can mark packets (by sending a
source quench) when operating in the probabilistic marking region, but
not discard these packets. With a tighter feedback loop, the information
might get there in time to prevent loss.
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:30 EST