RE: [Trigtran] TRIGTRAN LinkUp first draft available

Spencer,

My apologies.  You are correct both about your mechanism and the way in which I misunderstood it.

Martin

> -----Original Message-----
> From: Spencer Dawkins [mailto:spencer@mcsr-labs.org]
> Sent: Thursday, August 07, 2003 6:05 PM
> To: Trigtran Mailing List
> Subject: Re: [Trigtran] TRIGTRAN LinkUp first draft available
> 
> 
> 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" <martin.duke@boeing.com>
> To: "Spencer Dawkins" <spencer@mcsr-labs.org>; "Trigtran Mailing List"
> <trigtran@ietf.org>
> Cc: "Henderson, Thomas R" <thomas.r.henderson@boeing.com>
> 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:spencer@mcsr-labs.org]
> > 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
> > Trigtran@ietf.org
> > https://www1.ietf.org/mailman/listinfo/trigtran
> >
> 
> 
> _______________________________________________
> Trigtran mailing list
> Trigtran@ietf.org
> https://www1.ietf.org/mailman/listinfo/trigtran
> 

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