Subject: [BXXPwg] Definition of SEQ fields in TCP mapping document

From: "Steven E. Harris" <[email-masked]>
Date: 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        :: [email-masked]
Tenzing                 :: http://www.tenzing.com

_______________________________________________
BXXPwg mailing list
[email-masked]
http://lists.invisible.net/mailman/listinfo/bxxpwg

---

From: "Marshall T. Rose" <[email-masked]>
Date: Mon, 15 Jan 2001 15:27:02 -0800

> Is this heresy?

yes. it's called "ackno" because it's acknowledging something that's
received.

an implementation is free to implement whatever algorithms it finds useful
providing that its external behavior matches the specification.

what this means is that you're free to send SEQs asynchronously, but when
you send them, ackno must accurately reflect what you've received. you can
just as easily get the effect you seek by playing with the size (parameter
3) instead of the ackno (parameter 2).

/mtr

---

From: "Steven E. Harris" <[email-masked]>
Date: 15 Jan 2001 16:19:28 -0800

> yes. it's called "ackno" because it's acknowledging something that's

[...]

> what this means is that you're free to send SEQs asynchronously, but
> when you send them, ackno must accurately reflect what you've
> received.

Okay. But it seems impossible for an outgoing SEQ's ackno to
correspond to *exactly* the number of bytes that have been received,
as the incoming and outgoing activity can be happening
concurrently. Is it sufficient to say that the ackno must be *less
than or equal* to the number of bytes received when the SEQ message is
composed?

> you can just as easily get the effect you seek by playing with the
> size (parameter 3) instead of the ackno (parameter 2).

Okay, I see your point there.

---

From: "Marshall T. Rose" <[email-masked]>
Date: Mon, 15 Jan 2001 19:04:03 -0800

> providing that its external behavior matches the specification.

what this means is that if you've structured your implementation so that you
don't know the exact number when you generate a SEQ, then the external
behavior of your implementation should not indicate this. so, using a policy
like "less than or equal" is likely to keep up appearances.

/mtr