Re: [Trigtran] TRIGTRAN LinkUp first draft available

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

Dear Martin,

I am confused. Let me try to dig out a bit.

The current LinkUp draft is an end-to-end mechanism - no intermediary
is involved, and no intermediary modifications (to allow buffering or
ACK-from-intermediary) are required.

If a sending TCP sees an iimmediately-adjacent interface go active
("LinkUp"), the sending TCP already knows everything it needs to know,
in order to short-circuit an RTO timer and retransmit - just send the
first queued packet available from the application.

LinkUp covers the case where a receiving TCP sees its
immediately-adjacent interface go active. The only in-band signal the
receiving TCP can send to indicate LinkUp to the far-end sending TCP
is an ACK - that's the "hint" for the far-end sending TCP to
short-circuit its RTO timer and retransmit.

Are we talking about the same thing? (I'm wondering if you're thinking
about buffering data packets at an intermediary, which sees its
immediately-adjacent interface go active and retransmits the data
packet)

Spencer

----- Original Message ----- 
From: "Duke, Martin" <[e-mail]>
To: "Spencer Dawkins" <[e-mail]>; "Trigtran Mailing List"
<[e-mail]>
Cc: "Henderson, Thomas R" <[e-mail]>
Sent: Thursday, August 07, 2003 5:16 PM
Subject: RE: [Trigtran] TRIGTRAN LinkUp first draft available


Spencer,

Have you considered buffering the DATA packets rather than the ACKs?

This has significant benefits:
- The middlebox doesn't have to buffer packets until the outage is
detected, since DATA will be retransmitted by the endpoint anyway.

- sender-side modification is not strictly necessary.  Consider:
The DATA packet buffered will either be new to the receiver, or of an
earlier sequence number.  In either case, if it was retransmitted by
the sender, the sender hasn't seen the ACK for it. The receiver will
generate either an ACK or a DUPACK, but it will advance the sender's
"left edge" and generate new transmissions.

Thoughts?

-Martin

> -----Original Message-----
> From: Spencer Dawkins [mailto:[e-mail]]
> Sent: Tuesday, August 05, 2003 10:33 AM
> To: Trigtran Mailing List
> Cc: Jon Peterson; Allison Mankin
> Subject: [Trigtran] TRIGTRAN work moving to new locations
>
>
> Just to let people know my/Carl's current understanding of
TRIGTRAN -
> and Jon and Allison can correct any misstatements, of course!
>
> We gave a TRIGTRAN perspective at the ALIAS BoF in Vienna
> (http://www.ietf.org/ietf/03jul/alias.txt), and it looks like the
> following things are happening:
>
> - Hui-Lan and Kevin are expecting to develop mechanisms that would
> support "Performance Enhancing Proxies"
> (http://www.ietf.org/rfc/rfc3135.txt), as described in PILC, as part
> of a broader class of problems, so most of the TRIGTRAN notification
> discussion should move to ALIAS (TO JOIN:
> http://mailman.berkeley.intel-research.net/mailman/listinfo/alias)
>
> - Part of this work will include characterization of the services
> offered by intermediaries, so this portion of TRIGTRAN will move to
> ALIAS as well
>
> - the LinkUp work will continue, but will move to TSVWG, because no
> intermediaries are involved in the current draft
>
(http://www.ietf.org/internet-drafts/draft-dawkins-trigtran-linkup-00.
> txt)
>
> I'm expecting to send out an updated LinkUp draft in the
> not-too-distant future, but we didn't really get to talk about the
> current draft in Vienna, so I'm very eager to hear comments before
we
> sail into TSVWG - first impressions matter, of course.
>
> And thanks for your help and feedback. Carl and I put up a full page
> of acknowledgements in San Francisco, and we probably missed people.
> We couldn't have gotten this far without you.
>
> Spencer, for Spencer and Carl
>
>
> _______________________________________________
> Trigtran mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/trigtran
>


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