RE: [Trigtran] TRIGTRAN Justification

[Kacheong Poon <[e-mail]>]

Included message from "Spencer Dawkins" <[e-mail]>:

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

This is the reaction to such event you are referring to.  What I
was trying to find out is whether trigger is a good mechanism
to do such signalling.  IMHO, it is not.  An end2end mechanism
is preferred, and I think it can achieve the same thing.  We
can investigate what an appropriate reaction to such event is
later.

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

Yup, there can be end2end mechanisms for such event.  Trigger is
not really needed.

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

To me, Experimental does not necessarily mean that it won't be
deployed in real world.  It depends on what that change is.
NewReno is widely deployed (there is a commercial implementation
even before RFC 2582 was published) and it is still Experimental.
If I remember correctly, SACK (RFC 2018) was not published as
a Proposed when it first came out (I may be wrong here), and
there were commercial implementations.  Before ECN (RFC 2481)
became a Proposed (RFC 3168), there was implementation deployed.
And when it was published, there was commercial implementation.
I won't consider such change pace as slow.

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

I guess another point to look at is where that change is mostly
needed.  Please correct me if I am wrong, it seems to me that so
far the majority of voice for such notification comes from
wireless communication.  And I guess those devices are only started
to appear, which means that there will be continuous development.
The inertia not to change in this sector is not there.  As a matter
of fact, it is better to have an end2end change than a change which
requires cooperation of routers.  Routers are deployed already,
while those devices which make use of the change are not there yet.
Which is harder to change?

In summary, if the change is well thought of and the benefits of
such a change is great, it will be deployed.  Both are necessary
conditions, I think.

>----


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