On Wed, Jun 27, 2012 at 8:46 AM, Mark Rejhon <[email protected]> wrote: > On Wed, Jun 27, 2012 at 3:12 AM, Kevin Smith <[email protected]> wrote: >> >> Given reliable underlying streams (i.e. XEP-0198 between the servers) >> you should, in all of these cases, receive either an unavailable >> presence from the recipient or receive message bounces if an RTT >> element is missed. > Even with XEP-0198, and even with good stream resumption, the sender may > have spent 30 seconds typing 200 keypresses during an unavoidable network > stall (i.e. lost WiFi / 3G mobile phone reception). Even with perfectly > bug-free stream management, you still have to do a message catch-up of some > kind!
We're at risk of veering violently off-course here, but ... When using stream resumption on that sort of time scale there doesn't need to be any catch-up performed by the sender, as the recipient will receive all of the individual edits that the sender transmitted during the outage when they resume the session. > Perhaps this should be called "real time message catchup event" rather than > a "retransmission"? > I chose "retransmission" terminology because it was a simple catch-all word? > What about calling them "Message Resets" instead of "Retransmission"? > Is there better terminology? I don't think the terminology is particularly hurting here. Retransmission seems perfectly accurate for what's going on, although if you do feel a need to change it, Message Resets seems accurate too. >> Retransmission seems entirely appropriate when an entity that >> previously didn't support RTT (e.g. because it was offline) starts to >> support RTT - but frequent retransmission because some entity along >> the path has failed seems wrong to me. > Again, I now think it's a terminology issue. > The word "retransmission" may be wrong. I don't think it's the terminology - however you word it it's still sending a summary of the previously transmitted data in case some entity has failed en route, and this seems inelegant at this layer. I note that in the scenario you describe (30 second mobile data drop), the recipient will end up with three retransmissions/resets and all of the interim edits waiting for them when they resume their session - so there are downsides as well. However, as I'd noted below, this is not going to be an operational problem (I think) in most environments most of the time, and I'm not jumping up and down to have it removed. >> With that said: If retransmission only occurs during transmission of a >> stanza that would otherwise have already been sent containing an edit, >> this is probably not going to have a significant detrimental effect on >> most networks (although I'm aware of some networks where RTT sounds >> like a good idea but the extra bandwidth could tip it over the edge), >> except in the case of these hypothetical 64k and upwards copy/paste >> messages (and I suspect the XEP should suggest that RTT be disabled >> for copy/paste messages), which horrify me. > > > I have a better suggestion: I should find a place in the document, perhaps > in "Congestion Considerations": > "The sender's message entry ideally needs to have a reasonable maximum > length limit, to allow real time text to be always available without the > congestion concerns of large message stanzas, such as those during abuse of > large copy-and-pastes." A suggested limit of ~1000 characters seems reasonable to add to this as well (Which roughly ties in with your suggestion of a 2048byte limit in your UTF-16 text box, I think). /K
