RE: [Trigtran] TRIGTRAN Justification

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

Hi, Kacheong,

What I'm getting from your e-mails is that we're 
missing a possible path forward.

I've been looking at only two choices:

- implicit end-to-end signaling, and 
- explicit triggers

If I'm getting your point (please let me know if not), 
you're thinking of a third choice,

- explicit end-to-end signaling

Would you see this as part of TCP, 
or a completely different mechanism?

I don't own stock in triggers, you know... 
We COULD change the name of the mailing list!

Spencer

> -----Original Message-----
> From: Kacheong Poon [mailto:[e-mail]]
> Sent: Friday, January 17, 2003 1:11 PM
> To: Spencer Dawkins; [e-mail]
> Subject: RE: [Trigtran] TRIGTRAN Justification
> 
> 
> 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