Re: [clue] Benjamin Kaduk's Discuss on draft-ietf-clue-protocol-17: (with DISCUSS and COMMENT)

[Ben Campbell <[e-mail]>]

I haven’t finished writing up my notes yet, but I have some similar concerns. Comments below:



> On Nov 19, 2018, at 12:55 PM, Adam Roach <[e-mail]> 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.

IIRC, there are some situations where an endpoint sits in a state and waits for a message from the other side. Even with SCTP, there’s the possibility the other side doesn’t send that message.  I realize that might be an implementation error, but does that mean the endpoint just waits until the session ends? If that’s the case, why are timeouts even mentioned?

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

I’m not sure it’s reasonable for the protocol to depend on SIP eventually closing it down, as the SIP session could be arbitrarily long lived. “Wormwhole” conferences that are nailed up for days, months, or even years are not all that uncommon these days. Are those sorts of things in scope?