Re: [Trigtran] TRIGTRAN Justification

Included message from "carlw@mcsr-labs.org" <carlw@mcsr-labs.org>:

>----
>Below is a writeup on justification assessment
>for TRIGTRAN.  Spencer and I are looking to
>include the text in a framework/requirements
>document.
>
>Now seems a good time to discuss justification
>with the recent emails.
>----

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.

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.

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?

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