RE: [Trigtran] TRIGTRAN Justification

Hi, Kacheong,

Thank you for the helpful feedback. I have some responses inline, and am interested in other opinions, too.

Spencer

> -----Original Message-----
> From: Kacheong Poon [mailto:poon@cs.wisc.edu]
> Sent: Tuesday, January 14, 2003 11:50 PM
> To: carlw@mcsr-labs.org
> Cc: trigtran@ietf.org
> Subject: Re: [Trigtran] TRIGTRAN Justification
> 
> It seems to me that the write up is trying to justify
> some form of notification mechanism, not necessarily
> trigger.  I am in favor of some form of such mechanism.
> But I think trigger is the wrong mechanism to investigate.
> We have learnt from ICMP that trigger is problematic.
> This point was raised in the IETF BOF, as mentioned in the
> minutes.  I don't see any discussion suggesting the
> experience we learnt is wrong.

Again - not as a direct reply to your e-mail - Carl and I have been working on a writeup about our ICMP experience. I'll post it to the mailing list in a few minutes.

> 
> Using the example in the write up.  Assuming a simple
> 802.11b link, the end host's IP stack is well aware of
> the link up and down (association/reassociation with
> different access points) events.  If we use some form
> of end2end notification mechanism, kick start(?), in
> the transport level, the same benefits described
> in the write up can be achieved.  What is the advantage
> of using trigger, a form of notification outside of
> any transport level connection context?  If TRIGTRAN is
> only going to focus on access link, it seems that other
> end2end notification mechanism will have the same effect,
> but without those problems with trigger.

I'm certainly not against end-to-end notifications!

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

Again, I'm sending a pointer to some excellent discussions at TSVWG Adelaide to the mailing list (not just in response to this e-mail - Allison has been referring to it in our discussions, and I finally chased it down tonight).

> 
> So again, what is the problem with notification mechanism
> similar to ECN?  This kind of mechanism will also work
> with non access link, as demostrated with ECN.  Why not
> follow the same idea?

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?

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