Re: [Isms] Transport protocol discussion

[Wes Hardaker <hardaker at tislabs.com>]

>>>>> On Mon, 01 Aug 2005 09:12:58 -0700, Eric Rescorla <ekr at rtfm.com> said:

Eric> My $.02:

Eric> The important transport question is whether support for datagram
Eric> mode is a requirement. If it is, that substantially constrains
Eric> the solution set--and potentially requires some more design work
Eric> :)

[I'm not going to make the meeting later today due to a conflict,
though I hope to listen from a different room...  the end result is
that I'll ramble on now instead ;-]

I think it would be best, personally, to have a result with a choice.
Unfortunately, that is looking less and less likely.  The thing that
concerns me the most is that we're trying to make a decision about the
need for a datagram mode without any hard data (because none is
available).  We don't have any hard data papers anymore telling us how
well modern TCP algorithms and network architectures have improved
things.

A lot of people like to state that the need for UDP is beyond us and
that SNMP shouldn't need it anymore because TCP works just fine these
days.  But in actuality, I think the human-half of us is what is
measuring that metric.  I do have problems with TCP sessions all the
time in broken networks (frequently wireless).  But they're fixable by
restarting the TCP session.  The concrete example is that I've
probably restarted ssh connections multiple times in this week alone
because the TCP session properties had made my shell worthless from a
responsiveness point of you.  But it's easy to fix: I typed "exit" and
relogged on.  The delay was not huge for a human (5 seconds maybe), my
shell history was restored through the use of a decent shell, and it
happened at the right time (I noticed when things weren't responsive
and made the decision myself).  When using HTTP, I hit the stop button
and then hit reload.  Who, seriously, hasn't done that on a
semi-regular basis because you the human know something is wrong and
that will often fix the problem?

My worry is that coding that human decision process about when to
restart a broken TCP session because recovery will be faster by
restarting than waiting for the TCP stack to fix the session will be
impossible.  I'm not at all convinced that TCP sessions are stable,
based on my experience over the last few years.  I do think they've
gotten better, but I'm not willing to bet the management of my network
on it.

I'm not at all saying that UDP should be the only solution.  I'm
saying I don't know what the best choice is, but I'm fairly convinced
that no one actually knows.  I haven't seen any recent studies on the
subject and I don't think we'd be doing the future service by forcing
the selection of one or the other.  I'd even be tempted to make 2 MUST
transports, one UDP and one TCP because of this.  But I can't believe
I just said that, because now I'm about to get flamed.

-- 
Wes Hardaker
Sparta, Inc.

_______________________________________________
Isms mailing list
Isms at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms