Subject: RE: [midcom] pre-midcom - simplicity vs generality

From: Steve Davies <[email-masked]>
Date: Mon, 26 Nov 2001 22:22:06 -0000

See below:

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]]
Sent: 26 November 2001 18:23
Cc: [email-masked]
Subject: Simplicity vs. generality (was Re: [midcom] 2x allocate vs
FANTOM)

Rohan Mahy wrote:

[snip]

>> 
>> Understood.  This is another classic simplicity vs. functionality
tradeoff.

Ben Cringle then wrote:

> And there lies the crux of the problem. If the pre-midcom protocol is 
> expected to have a short lifespan, that is it will eventually be 
> supplanted by the real midcom protocol, then I would expect that we 
> would want to err on the side of simplicity.

FANTOM is not complex. It is unfamiliar. I've already explained that FANTOM
and TURN use identical concepts to solve the pre-midcom problem. The methods
that are in FANTOM are there for a reason. If you can show otherwise, we'll
take them out.

TURN is simple because it is unfinished. We have shown that TURN does not
handle RTP properly. A new element has to added. A method has to be devised
to stop NATs timing out and so on...

Not so long ago, SIP claimed to be simple. Look at it now. If the IETF were
just starting on a SIP-like protocol and SIP were submitted as it is today,
by this reasoning it would be dismissed as too complex. But the reason it is
large is to support the functionality it has to support, and the adoption of
such a proposal would say a lot of development effort and time to market.
The same is true of FANTOM.

Steve

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

---

From: Ben Campbell <[email-masked]>
Date: Mon, 26 Nov 2001 20:19:25 -0600

Ben Cringle? :-)

But to the meat of the matter--My apologies;I was being flip and did not 
exactly express what I was attempting to express.

I was not arguing about the relative complexity of two different ways of 
accomplishing "A". Rather, I was arguing about the complexity of 
accomplishing A, B, and C, when perhaps only A is required.

It seems to me that the primary argument in favor of FANTOM is that it 
does more than STUN/TURN. But it seems we do not have consensus on how 
much is enough. The argument that FANTOM is only a little more complex, 
and also does B and C, is not useful if the requirements are limited to A.

If we were talking about the midcom protocol itself, then it might make 
sense to add more generality than explicitly required, if it were cheap 
to do so. But for a protocol designed to solve a problem that should in 
itself go away eventually (otherwise we have failed at midcom), I think 
it makes less sense.

As for the primary in STUN/TURN you mention in this note: Bob Penfield 
pointed out that the original STUN draft does address NAT binding 
keep-alives, and the RTCP issue can be fixed with a very minor addition 
to TURN.

I have seen firewall traversal, explict closure of forwarding, and 
extensibility listed as advantages of FANTOM. I have not seen any 
general agreement that they are requirements for the pre-midcom protocol.

Steve Davies wrote:

> FANTOM is not complex. It is unfamiliar. I've already explained that 
> FANTOM and TURN use identical concepts to solve the pre-midcom problem. 
> The methods that are in FANTOM are there for a reason. If you can show 
> otherwise, we'll take them out.
> 
> TURN is simple because it is unfinished. We have shown that TURN does 
> not handle RTP properly. A new element has to added. A method has to be 
> devised to stop NATs timing out and so on...
> 
> Not so long ago, SIP claimed to be simple. Look at it now. If the IETF 
> were just starting on a SIP-like protocol and SIP were submitted as it 
> is today, by this reasoning it would be dismissed as too complex. But 
> the reason it is large is to support the functionality it has to 
> support, and the adoption of such a proposal would say a lot of 
> development effort and time to market. The same is true of FANTOM.
> 
> Steve
>