[Standards-JIG] rfc3920bis: Stanza Acknowledgements

[Justin Karneges]

On Monday 06 November 2006 4:07 pm, Bruce Fitzsimons wrote:
> Having sequence numbers progress in an orderly fashion also helps
> efficient implementation -- if every id is just an opaque tag then you
> have to linearly search your sending queue to find the matching start
> point. The potential for duplicates also creeps in fairly easily if
> people pluck them from undefined places, you end up needing another
> requirement saying "don't duplicate id's within <criteria> time". The
> criteria involves a time envelope including both sender and reciever so
> it is a bit hard to define programmatically.

In the original proposed text, an opaque tag would be enough because only the 
last received value would matter.  It would not have to be a number, because 
the recipient of the value wouldn't be comparing it to greater or lesser 
values.  In fact, it wouldn't even compare it to anything.  There's no linear 
searching whatsoever.  There is simply just one stored value, which is 
divulged to the peer, when the peer asks for it.

That said, in the newer ideas from my last mail, where unsolicited acks 
respond to sequence numbers, the value certainly does need to be an 
increasing counter.

> >> 1. Um, I see an internal contradiction here. You say: "Acks SHOULD be
> >> sent as soon as possible, and MUST NOT be withheld for any condition
> >> other than a timeout.". Fair enough. But then your example shows the
> >> opposite behaviour to that which you've recommended? I'm confused.
> >
> > <snip>
> >
> > Do you have a suggestion about how to make this more clear?
>
> Ok. I think Dave Cridland has provided an excellent response, although
> I'd like to make the timers shorter. I think we're all agreeing that a
> one-ack for many packet model is the scalable way to go though. We're
> just debating how explicit we need to be about what we're acking, and
> how often that needs to be :-)

I disagree with having explicit timeout values regarding acking.  As I wrote 
in my other message, acking could be something you wait for indefinitely.

I can understand why people may want to be disconnected sooner, such that 
presence is more properly reflected.  It sucks to send a message to someone 
you think is online, when they are not really online at all.  However, the 
greater problem, IMO, is the fact that the message might go into a black 
hole.  At least with acks, we won't lose anything, even if the other person 
doesn't fall offline until a 20-minute TCP retransmission timeout.

> I'm intrigued by your argument that heartbeat/ping is different to
> reliable delivery. This is just so different from other protocols I'm
> familiar with that have them interlinked (including TCP, SCTP, SMPP, EMI
> and internal protocols). Heartbeats are fill-ins for when there is
> insufficient real data to validate the connectivity in these protocols.
>
> It comes back to the discussion of TCP connections vs XMPP streams --
> are pings checking the heath of the TCP connection while acks
> potentially cross multiple TCP connections without concern?

This isn't TCP vs XMPP, but "health of the stream" vs "what has been 
accepted."  This difference is really only important if we consider server 
throttling.

The throttling problem first occurred to me when I was working with XEP-47 
(Inband Bytestreams).  The problem is that there is no mechanism for 
flow-control between the client and the server, and so it is difficult to 
decide just how fast you should send the data packets.  As it stands now, you 
either send too fast and get penalized, or send slowly (with a hard-coded 
sleep value) which is suboptimal.

I figured one good solution to this, if we had stanza acks, would be for the 
server to withhold an ack if the client is sending too fast.  This way, the 
client can send as fast as allowed by the server, simply by waiting for an 
ack before sending the next packet.

This is probably all fine and good for everyone, but where it gets tricky is 
when you consider the downright harsh penalties that are in some servers.  
With jabberd, you could be penalized on the order of minutes.  If a client 
has a 30 second ack timeout, there's trouble.  We either needs acks to be 
sent immediately, even if the client is being penalized (which means 
flow-control is completely lost, and the client is in the dark again), or we 
need a separate mechanism for doing timeouts.

I don't mean to make a false dilemma out of this; there are other 
alternatives, like using sane throttling values, or ditching throttling 
entirely.

-Justin