Subject: Re: [midcom] Protocol eval: 2.1.2 RSIP - proposal to change score and text

From: [email-masked]
Date: Tue, 6 Aug 2002 21:18:59 -0500

Melinda,

As I see it, the situation here is no diffrerent for RSIP than for any
of the other protocols.

Or any different than with any client / server protocol where a client
communicates with multiple servers simultaneously.

The client is going to have to keep some state for each server that it
simultaneously communicates with, which would include, e.g., the TCP
socket used to exchange messages with that server.

If you're only communicating with one server and ya want something done,
well, ya send a request to that one server and it either works or doesn't.

If you're communicating with more than one server, ya presumably have to
decide in some way or another which server to send the request to.

Maybe part of that decision process, even in the case of communicating
with only one server, is the possibility that ya ain't yet communicating
with the right server, so ya need to open a connection with that server
before ya send the request.

As I said, I believe all of this is necessary not just with RSIP, but with
any of the other protocols. Unless the client library has some kind of
automagic, smart request router built into it. But I would think that's a
library implementation issue, not a protocol design issue.

All of this seems so obvious to me that I'm afraid I misunderstood what
you were asking. Did I miss something? It wouldn't be the first time, and
it probably won't be the last time, either. :-)

Jim

Melinda Shore <[email-masked]>@ietf.org on 08/05/2002 05:42:02 PM

Sent by:  [email-masked]

To:   James Renkel/MW/US/3Com
cc:   midcom <[email-masked]>
Subject:  Re: [midcom] Protocol eval: 2.1.2 RSIP - proposal to change score
      and text

> I propose that the score of RSIP for this requirement be changed to T,
> and the RSIP text under this requirement be changed to:
>
>      RSIP allows a client to simultaneously have RSIP sessions with
>      multiple RSIP gateways.

I hope that you'll also provide some text describing the
complexity associated with having one "virtual" interface/
address on the host for each middlebox with which it's
communicating.

Melinda

_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

---

From: Melinda Shore <[email-masked]>
Date: Wed, 07 Aug 2002 08:50:42 -0400

> From: [email-masked]

> As I see it, the situation here is no diffrerent for RSIP than for any

The difference may be in magnitude rather than in kind, but
it's certainly there.  With a typical client-server
implementation you're selecting based on a file descriptor
(socket) that has application state associated with it.
With RSIP, as I understand your proposal, you've got the
additional overhead of a "virtual" network interface for the
borrowed address, which pushes more state into the OS or
driver as well as the routing tables.

Melinda