Subject: RE: [midcom] London meeting time

From: "Christian Huitema" <[email-masked]>
Date: Fri, 13 Jul 2001 18:37:01 -0700

I am a great fan of designing protocols over UDP. However, we have to
consider the practical problem of the packet size. Using IP
fragmentation should be a big no-no -- it is a major source of problems
as soon as the network systematically drops a fragment of each packet,
and murphy's law says that in some cases it will. (In fact, we have
practical examples.) Any protocol we do will have a strong security
component; we will at some point have to carry certificate chains;
certificate chains can absolutely be trusted to not fir in 512, 1260 or
even 1500 bytes, either because the keys have grown long or because
there are many elements in the chain. Frankly, I would feel much more
confident if the main transport was TCP.

> -----Original Message-----
> From: Eliot Lear [mailto:[email-masked]]
> Sent: Friday, July 13, 2001 3:08 PM
> To: Andrew Molitor
> Cc: [email-masked]
> Subject: Re: [midcom] London meeting time
> 
> We've gotten into protocol selection/design.  Perhaps this discussion
> is a
> bit early, but anyway...
> 
> As anyone who followed the RSIP discussion knows, I have a very strong
> bias AGAINST having an implementation be both TCP AND UDP.  There are
> two
> and a half closely related reasons for this:
> 
> 1.  It's more code to write and maintain
> 
> 2.  Any lesser used code path is a potential security hazard, and
> certainly a haven for bugs.
> 
> 2.5 One of our touted reasons for success over other alternatives has
> been
> our LACK of options.
> 
> Since the question is really what form should state remain, I am
> inclined
> to suggest that we decide which we need to guard more carefully-
> latency
> or the resources on the middlebox, while not trading off security,
> pick
> one and run with it.  Let's not have another protocol that is both a
> floor
> wax AND a dessert topping.
> 
> Eliot Lear
> 
> Andrew Molitor wrote:
> >
> > On Thu, 12 Jul 2001, Melinda Shore wrote:
> >
> > > At 08:30 PM 7/11/01 -0500, Andrew Molitor wrote:
> > > >        My personal feelings are that UDP is the way to go, since
> > > >TCP's backoff behavior is just not what you want in a real-time
> > > >environment.
> > >
> > > I believe that all IETF protocols are now expected to employ
> > > TCP-compatible congestion response mechanisms.  That's not an
> > > argument against using UDP, but it is something to be aware of.
> >
> >         If I put on my standard hat, I arrive pretty quickly at
> > the 'should run over UDP or TCP' exactly for these reasons.
> Obviously
> > a TCP implementation would do that vis a vis congestion, and
> > a UDP implementation would let you play games. This seems to be
> > pretty common, and I'd be surprised if we DON'T get there.
> >
> > _______________________________________________
> > midcom mailing list
> > [email-masked]
> > http://www.ietf.org/mailman/listinfo/midcom
> 
> --
> Eliot Lear
> [email-masked]
> 
> _______________________________________________
> midcom mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/midcom

_______________________________________________
midcom mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/midcom

---

From: Andrew Molitor <[email-masked]>
Date: Fri, 13 Jul 2001 22:36:30 -0500 (CDT)

Would I be burned at the stake for suggesting we declare
transport Sombody Else's Problem, and simply make it a (strong)
desideratum that the protocol be (efficiently) implementable over
either TCP or UDP?

	I think if we did this, it would be necessary to demonstrate
useful implementations over both before getting to RFC, but presumably
it's possible to just say it initially.

		Andrew

---

From: Eliot Lear <[email-masked]>
Date: Fri, 13 Jul 2001 22:31:49 -0700 (PDT)

As far as requirements are concerned, state the requirements, and let the
proposed solutions sweat on how to fulfill them.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 13 Jul 2001 22:36:15 -0700 (PDT)

Christian,

I am NOT going to stand on my head to argue for UDP at this point in time.
I would vastly prefer TCP over having to do both.  But in any event, why
not we write down the underlying requirements (e.g., large #s of
transactions per second) and let the candidate protocols fulfill them?

Eliot

---

From: Melinda Shore <[email-masked]>
Date: Sat, 14 Jul 2001 09:02:19 -0400

>desideratum that the protocol be (efficiently) implementable over

I'm not sure how many times it has to be repeated, so I'll do
it again just for the heck of it:  WE ARE NOT SPECIFYING MECHANISM
IN THESE DOCUMENTS.  

"Runs over TCP" is not a requirement.  "Transport must provide
assured delivery" is a requirement.

Thank you, and the next person who tries to discuss whether we'll
run over TCP or UDP or AAL5 owes me a drink - an expensive one - 
in London.

Melinda

---

From: Andrew Molitor <[email-masked]>
Date: Sat, 14 Jul 2001 11:35:55 -0500 (CDT)

> it again just for the heck of it:  WE ARE NOT SPECIFYING MECHANISM

	My apologies, I thought it was clear that I meant
declaring transport somebody else's problem in ALL midcom
documents, not just the ones where it's perfectly clear to
everyone that such discussion has no place. I keep assuming
that everyone knows I'm not an idiot, and that they will
therefore interpret my remarks in that light. My bad.