Subject: Re: [clue] Benjamin Kaduk's Discuss on draft-ietf-clue-protocol-17: (with DISCUSS and COMMENT)
From: Benjamin Kaduk <[email-masked]>
To: Adam Roach <[email-masked]>
Cc: The IESG <[email-masked]>, [email-masked], "Daniel C. Burnett" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Date: Mon, 19 Nov 2018 13:01:40 -0600
List-Id: CLUE - ControLling mUltiple streams for TElepresence <clue.ietf.org>

On Mon, Nov 19, 2018 at 12:55:04PM -0600, Adam Roach wrote:
> Trying to help out a bit on one of the discuss points...
> 
> On 11/19/18 12:25 PM, Benjamin Kaduk wrote:
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > Thanks for the generally clear and well-written document!
> > I would like to discuss whether there needs to be more prominent coverage
> > of timers/timeouts, especially as relating to the state machines.  (I'd be happy
> > to learn that this is well-covered elsewhere in the document set; I just haven't
> > run into it yet.)
> 
> 
> The initial document included several timers that triggered 
> retransmissions of messages -- but since the CLUE protocol uses TCP as a 
> substrate, these kind of application-level retransmissions can cause a 
> spike of traffic when the networks starts getting congested, which is 
> the opposite of what we want to happen. So they were removed, and the 
> protocol now relies exclusively on the reliability mechanisms provided 
> by TCP both for retransmission and for detection of connection failures.

(SCTP now, but sure.)

> In terms of supervising the overall lifetime of the state machines, it's 
> important to keep in mind that these operations always take place within 
> the context of a larger session (e.g., a SIP session), which naturally 
> limits how long the state machines can live: at the end of the 
> corresponding session, all CLUE state goes away.

So it seems the question is scoped to what to do with a peer that is
behaving properly with the SIP session and claims to negotiate CLUE at the
SIP layer, but then fails to actually send one of the required CLUE
messages.  Section 6 of this document only mentions "a timeout error is
raised" twice, in some informal discussion of why the initiation phase
might fail, which is part of what got me thinking about the question.

-Benjamin