RE: [Trigtran] TRIGTRAN Justification

[Kacheong Poon <[e-mail]>]

Included message from [e-mail]:

>----
>--  Is TRIGTRAN only considering TCP, or can other transport
>protocols such as RTP over UDP, or raw UDP with TFRC, also make use of
>it?

I think this is one important question to answer.  I
don't know if this is one of the original motivations of
trigger to be an "universal notification mechanism" for
all transports.  I agree that it would be nice, but it
is probably wrong to do it.  We know that there is not
an "universal transport" and it is probably wrong to have
one.  The same reasons apply to transport notification
mechanism.

>--  If it's supposed to help other protocols like RTP over UDP, or
>UDP using TFRC for rate control, then we need to keep in mind that
>unlike TCP, RTP does not have a protocol field in the IP
>header. This means that given a stream of UDP packets, one cannot
>*reliably* say if these packets belong to a RTP session, of if
>they belong to some other protocol on top of UDP which just
>happens to have the same format (It's good to be a little paranoid
>while designing a new protocol, so don't bite off my head if you
>think that the probability of such collisions are small) This also
>means that TRINGTRAN routers cannot be stateful (i.e., one cannot
>estimate RTT etc for a "flow"--whatever that means).
>
>The framework should indicate such issues, or advise against using
>TRIGTRAN for UDP applications...

The above is a good reason not to have trigger as a
notification mechanism.  The mechanism has to be aware of
end2end transport context to be effective.  This means that
it is probably good to do it end2end.

>--  If it's supposed to work only for TCP then it will be useful
>to consider how it will work in the presence of IPSec tunnels. Of
>course we can just say that it will not work with IPSec, but that
>doesn't sound right (to me). Shouldn't IETF protocols work in the
>presence of all the other IETF protocols.

Another point against trigger.  An end2end notification
mechanism does not have this problem, or can get around it
easily, for example ECN.

>--  Since TRIGTRAN is only advisory, it should not have signals
>for which the transport layer does not have an in band counter
>part. For example, handoff has no in band counterpart for TCP/UDP
>and therefore such signals should not be present (but if they are
>present then it SHOULD be ignored by the transport)
>
>--  Also, for DoS attacks, TRIGTRANS should not only protect the
>transport protocol, but it must protect itself, too. (This is
>obvious, but it's probably useful to point it out explicitly.)
>>From the age-old example, one needs to consider how to handle IPv4
>fragmentation; how to respond to multiple anomalies etc so that
>the network is not flooded with TRIGTRAN messages..., etc.

Yet another point not to use trigger as a notification
mechanism.

I believe when people continue to look into trigger as a
transport notification, more and more problem will be
found, as we have learnt from ICMP.  I suggest we should
look at other forms of transport notification or how to
put notification into existing transports as the starting
point.

>----


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