Connected: An Internet Encyclopedia
RFC 1122 - 4.2.4.1 Asynchronous Reports

Top: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 1122
Up: 4. TRANSPORT PROTOCOLS
Up: 4.2 TRANSMISSION CONTROL PROTOCOL -- TCP
Up: 4.2.4 TCP/APPLICATION LAYER INTERFACE
Prev: 4.2.4 TCP/APPLICATION LAYER INTERFACE
Next: 4.2.4.2 Type-of-Service

### 4.2.4.1 Asynchronous Reports

There MUST be a mechanism for reporting soft TCP error conditions to the application. Generically, we assume this takes the form of an application-supplied ERROR_REPORT routine that may be upcalled [INTRO:7] asynchronously from the transport layer:

       ERROR_REPORT(local connection name, reason, subreason)

The precise encoding of the reason and subreason parameters is not specified here. However, the conditions that are reported asynchronously to the application MUST include:

- ICMP error message arrived (see 4.2.3.9)

- Excessive retransmissions (see 4.2.3.5)

- Urgent pointer advance (see 4.2.2.4).

However, an application program that does not want to receive such ERROR_REPORT calls SHOULD be able to effectively disable these calls.

DISCUSSION:

  These error reports generally reflect soft errors that can be ignored without harm by many applications. It has been suggested that these error report calls should default to "disabled," but this is not required.

Next: 4.2.4.2 Type-of-Service

Connected: An Internet Encyclopedia
RFC 1122 - 4.2.4.1 Asynchronous Reports