Subject: [BEEPwg] question about BEEP tcp mapping

From: "Michael Fortson" <[email-masked]>
Date: Thu, 7 Feb 2002 17:30:08 -0500

I've been reading through the BEEP RFCs (3080, 3081) and I was hoping
someone here could help me understand the TCP mapping better.  

I don't really understand why the use of SEQ frames and a sliding window
is necessary to avoid starvation and deadlock when the underlying
transport (tcp) already addresses these problems (although for ports,
not channels).  For instance, why can't the underlying TCP socket deal
with ensuring that peers don't send more data then the other can
receive?  

As far as BEEP flow control goes, would it be possible for peers to
negotiate a larger max-frame-size (restricted by 2/3rds of the TCP
max-segment-size) rather than increase the size of their windows?

Incidentally, I realize that I'm missing something -- I'm just hoping to
arm someone with enough ammunition to quickly point out what I've missed
:).

-Michael

_______________________________________________
BEEPwg mailing list
[email-masked]
http://lists.beepcore.org/mailman/listinfo/beepwg

---

From: Marshall Rose <[email-masked]>
Date: Thu, 7 Feb 2002 14:47:49 -0800

> with ensuring that peers don't send more data then the other can

with rfc3080, it's possible that you have more than one data exchange channel simultaneously active. in this case, you need to have a mechanism wherein the beep peers can negotiate how much each channel gets.

otherwise, you can get into a situation where one channel starves another one, potentially even channel 0...

> max-segment-size) rather than increase the size of their windows?

i'm not sure i follow what you're asking exactly. you can implement whatever algorithms you want, providing they are consistent with the guidelines given in rfc3081, e.g., priority queues.

/mtr

---

From: Darren New <[email-masked]>
Date: Thu, 07 Feb 2002 14:57:23 -0800

Michael Fortson wrote:
> not channels).

For the same reason that TCP has a window for each port.

> For instance, why can't the underlying TCP socket deal

They do. But what prevents channel 5 from overrunning the processing at
the peer and thereby making channel 7 have to wait for unrelated
processing?

Say you have two streams, channel 5 getting copied to the printer,
channel 7 going to the disk.  If the printer is very slow, channel 7
might get held up waiting for channel 5 to drain a large block of 20
pages of text. If channel 5's window is smaller than the printer's
buffer and doesn't get opened wider than the printer's buffer, channel 7
will never slow down.

> arm someone with enough ammunition to quickly point out what I've missed

You're not missing something. You just don't realize you already know
the answer.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
  The opposite of always is sometimes.
   The opposite of never is sometimes.
_______________________________________________
BEEPwg mailing list
[email-masked]
http://lists.beepcore.org/mailman/listinfo/beepwg