TCP and IDPR

[[e-mail]]

woody was absolutely correct in saying that one of the reasons that we
did not use TCP as the reliable transport mechanism for IDPR control
messages was because we did not want to tie IDPR to the TCP/IP
environment only.  there were other reasons as well.

the requirements for reliable IDPR control message transport included:
- retransmission in response to no acknowledgement.
- acknowledgement contingent upon message validity checks including
  length check, timestamp check, integrity/authentication value
  check, and valid IDPR control protocol.
there was no requirement for stream-oriented delivery of information.

TCP itself would not be able to perform the IDPR validity checks.
thus, to get the behavior we wanted, we would have to modify TCP so
that either it carried options containing timestamps and
integrity/authentication values and performed the proper IDPR-level
checks, or it passed the message to IDPR and did not return an ack
until IDPR determined that the validity checks were correct.  in
either case, it means modifying TCP.  such modifications to TCP also
mean that we should disable TCP flow control, which automatically
reacts to the failure to receive an acknowledgement.

as selective retransmission is not generally available with TCP, a
retransmission may force the retransmission of more than one message,
depending upon the size of the TCP window.  moreover, some of these
retransmitted messages may have been successfully transmitted the
first time.  this means a certain amount of resource waste.  moreover,
the failure of an individual control message to be properly received
can cause all messages behind it to wait for proper receipt.  as IDPR
control messages should be distributed quickly, this retransmission
delay is not desireable.

about fragmentation of large IDPR routing information messages: i am
not thrilled by the prospect of IP fragmenting and reassembling these
messages or of the loss of one fragment resulting in the
retransmission of the whole message.  however, the messages most
likely to be too big, namely configuration messages, are transmitted
infrequently.  hence, the extra cost will not be large when amortized
over all IDPR messages.

however, if we believe that frequently transmitted messages, such as
path setup messages, are likely to require fragmentation, then we
should seriously think about having IDPR perform its own
fragmentation.  what do you think?

m