TCP and IDPR

[Robert Woody Woodburn <[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.

Martha, I was trying to explain what I thought the motivations had been,
but I didn't necesarrily agree with all of them.  I think I remember that
Dave Mills had problems with any routing protocol using TCP for transport.
I know he wasn't thrilled with BGP using it, but I don't remember his 
argument.  Dave, if you have a chance, maybe you could chime in at this 
point.

Also, if IDPR is seen as an application above the transport, then I see
no reason why it can't speak TCP at the goesinta and TP4 at the goesoutta.
I think the key is allowing the model to be pliable to having tool based
requirements, rather than starting from scratch.  In this paradigm, TCP (or
the DNS or any other existing protocol), becomes a tool for development.
In a multi-stack environment, the tradeoff becomes what features of the 
tools become mandatory vs the availability of the features in other stacks.

    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.

Well, perhaps there was no requirement, but TCP certainly handles a lot
of things.  I think the problem is in the terminology and the model used
when describing the mechanisms required by IDPR.  With a reliable stream
transport, the requirement for IDPR ACKs goes away altogether, the U/D 
protocol is replaced by TCP keepalive messages (I'm not sure if TP4 has an 
equivalent, but I would suspect so).

    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.

I don't see where TCP ever would need modified.  You're talking about
incorporating functionality required by the IDPR model into a tool,
rather than flowing the model around the tool.  The validation functionality
could be on top of TCP, rather than at the same layer.  I don't see 
a problem.

    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.  

In the existing protocols, almost all control messages require an ACK.
Only U/D does not (Hmm, what did I miss...?  Is there any other?).

    moreover, some of these
    retransmitted messages may have been successfully transmitted the
    first time.  this means a certain amount of resource waste.  

Umm, but CMTP is already retransmitting.

    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.

Ah, now this is an important point and I agree at first look.  I think there
could be a solid case here for avoiding streams since there are many
different independent messages that should be able to supercede each other.
Although, I'd have to think a bit more to see where this would really be a
problem.  This is probably the weightiest argument against TCP.  However,
maybe we could also think about breaking things up some and use TCP for big
messages and CMTP for small things.

    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.

Well, TCP certainly avoids the fragmentation problem.

    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?

I tried to think of seem simple ways to do this, but it simply isn't
very simple.  I protest reinventing the wheel of TCP in IDPR.


wood y