[BXXPwg] Definition of SEQ fields in TCP mapping document

Steven E. Harris steven.harris@tenzing.com
15 Jan 2001 14:36:45 -0800

Section 3.1.3 of draft-ietf-beep-tcpmapping-06 defines the "ackno"
field of a SEQ message as:

| an acknowledgement number, that indicates the value of the next
| sequence number that the sender is expecting to receive on this
| channel

While at one point I found that easy to understand, my reaction to it
now is, "Huh?"

I've been envisioning a scheme in which SEQ frames could be sent at
times somewhat independent of when an incoming frame arrives. It seems
to me that the the window management messages must be consistent only
among themselves, not with respect to the "current" byte count on the
channel as suggested above.

If I approve 4096 bytes on a given channel, starting a byte 0, then,
after having received 3000 bytes decide to approve another 2048 bytes
(since my application is consuming its buffer quickly), then the
second SEQ message should be able to specify 3000 as its ackno, with
the window equal to (4096 - 3000) + 2048 = 3144. That is, assuming
we'd bother with the first SEQ (it's actually implicit in channel
creation, I think), we'd send

SEQ 1 0 4096
... later ...
SEQ 1 3000 3144

It shouldn't matter that in between the time I've decided to compose
and send this second SEQ message that more bytes may have
arrived. (Maybe by the time the SEQ goes out I've received 3177
bytes.) What should matter is that the sending side could still do the
proper math to know when to hold back its frames.

To continue the above example, the sender might say, "I've sent 3300
bytes. With this latest SEQ message in mind, I can send another 3144
- (3300 - 3000) = 2844 bytes before requiring further approval."

Is this correct? If so, we should massage the "ackno" definition
quoted above, as it sounds too stringent.

Also, why can't a SEQ message be "predictive," with the "ackno" higher
than what's actually been received? The math still works out the
same. Consider:

SEQ 1 0 4096
... later ...
SEQ 1 4096 2048

Again, when the sender gets this SEQ, it could say, "I've sent 3300
bytes. With this latest SEQ, I can send another 2048 - (3300 - 4096) =
2048 + 796 = 2844 bytes before requiring further approval." Tada!

Permitting such a "forward-looking" SEQ simplifies some of the
bookkeeping required to compose SEQ messages by decoupling the ackno
from the _actual_ received byte count. Is this heresy?

Steven E. Harris        :: steven.harris@tenzing.com
Tenzing                 :: http://www.tenzing.com