RE: [Trigtran] TRIGTRAN Justification

["Spencer Dawkins" <[e-mail]>]

Hi, Kacheong,

Thanks for your thoughts and questions.

For all - note that we're still writing the justification document. There ARE
still questions that need to be figured out! All comments welcomed...

My notes inline...

Spencer

> -----Original Message-----
> From: Kacheong Poon [mailto:[e-mail]]
> Sent: Thursday, January 16, 2003 9:29 PM
> To: Spencer Dawkins; [e-mail]
> Subject: RE: [Trigtran] TRIGTRAN Justification
> 
> 
> Included message from "Spencer Dawkins" <[e-mail]>:
> 
> >----
> >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.

What I'm thinking about here is giving a TCP sender a clue that what they're 
seeing with RTT time variation has little to do with congestion. I note that 
(per RFC 2988) we don't include retransmitted packets in RTO calculations 
(Karn's algorithms) - I'm wondering about, but not proposing, similar treatment 
when the TCP sender is notified of intermittant connectivity. 

> 
> >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.

This is the "backed off RTO timer" issue - after only one or two RTO backoffs, 
I'm looking at a really long interval after a host becomes reachable, before 
the other-end TCP sender reattempts the transmission. TCP Kickstart was a
proposal to solve this problem with end-to-end notifications.

> 
> >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?

You may be right. I hope not.

This is an Allison/Scott question, but my impression is that
there's a LOT of entrophy for TCP changes (to the point of proposed 
changes that orbit in Experimental RFC-land before they go to 
standards track).

> 
> 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.

I agree that this is a good thing to think about. I think it's also
good to think about the amount of entropy involved in making changes
to TCP to accomplish these tasks. I can't tell you what the right
trade-off is (that would be a BOF/WG concensus question, right?).

> 
> >----
> 
> 
> 							K. Poon.
> 
_______________________________________________
Trigtran mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/trigtran