RE: [Trigtran] TRIGTRAN Justification

Included message from "Spencer Dawkins" <sdawkins@cynetanetworks.com>:

>----
>The usage scenarios I'm looking at (speaking only for myself) include
>situations where (1) a very interesting trigger/notification is that one host
>isn't reachable, so it can't tell the other host about THIS happening, and (2)

As I mentioned in the previous mail, what benefit does this trigger really
have?  What is the advantage over the end2end notification I suggsted?
I guess they have to be made very clearly.  Just that one end cannot
be reached does not really justify that a trigger is needed.

>measured RTTs are seconds long, with pretty wide variances, so RTOs tend to be
>over 8 seconds, so I'd prefer not to rely on RTO as a notification.

Could you elaborate on this point?  The scenario mentioned in the
justification was to avoid the other end to timeout prematurely.  I
don't understand why an 8 seconds RTO matters here.  Or are you
suggesting that the trigger actually tells the other side that one
end has gone away forever?  And because RTO is 8 seconds, the trigger
can speed this up so that the other side will forget about the
connection quicker?  This does not sound right.  Please elaborate.

>You're raising (for the first time) an interesting question here - I know
>I've been assuming that it would be easier to create a new mechanism than to
>modify existing transports. Does anyone else have opinions about this? Is it
>realistic to add states to TCP that reflect new kinds of notifications, for
>instance?

It really depends on what the new mechanism is.  I don't think trigger
is a good mechanism at all.  If the trigger is advisory only and we know
that any machine can forge one, I am sure that all implementations will
simply ignore any trigger.  If this is the case, what is the point of
trigger?

I believe the basic criterion for a new mechanism is that it must
work more effectively than any solution by amending existing technology.
If people have not even looked at how existing technology can be
changed potentially, I'm afraid that thinking of a new mechanism at
this point is not a wise thing to do.

>----

							K. Poon.
_______________________________________________
Trigtran mailing list
Trigtran@ietf.org
https://www1.ietf.org/mailman/listinfo/trigtran