Subject: RE: packets of multiple users sent over the same TCP/IP session

From: Haim Rochberger <[email-masked]>
Date: Sun, 25 Jan 2004 19:20:02 +0200

Hi Valdis,

Thanks for the reply.

SMPP is a good example to what I am looking for, and I am trying to see if
other 
protocol foreseen in the future (or past) have the same characteristics:

The special thing about SMPP is that in the same TCP/IP session packet that
are really SMS embedded in IP 
are sent from one network element (called SMSC) to another (called ESME) -
so that the packets (i.e. SMS) belong to different mobile users.

In this case I cannot map the IP address of the TCP session to one specific
mobile subscriber - and the only way I can 
identify the subscriber is by "looking" on the SMPP layer (above the TCP)
and extract the subscriber mobile number.

Another example may be SMTP (not sure).

Anyway the thing I am trying to solve is whether I should consider this kind
of protocol characteristic as "special" and "rare", and so build a dedicated
solution for SMPP, or maybe I can expect to see many more such protocol and
so I should build a more generic solution.

It is obvious to me that a generic solution is better technically, but since
my resources (i.e. time) is limited, 
I need to see how rare this kind of protocol (same TCP/IP with packets of
multiple users) is common/expected.

Another characteristic of SMPP that I am looking for its "commonness" is the
fact that there could be many 
TCP/IP session from many SCSCs to ESMEs at the same time - and packets of
the SAME subscriber may appear 
on them at the same time...

Complicated :-)   that's my life (-:

yours,

Haim Rochberger

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Sun, January 25, 2004 6:43 PM
> To: Haim Rochberger
> Cc: [email-masked]'
> Subject: Re: packets of multiple users sent over the same 
> TCP/IP session
> 
> 
> 
> On Sun, 25 Jan 2004 15:42:28 +0200, Haim Rochberger 
> <[email-masked]>  said:
> 
> > I will appreciate your help as it will help in making a 
> better design
> > decisions.
> 
> Hmm.. been a while since I've had to post this. ;)
> 
> The first thing you want to do is take a step *back* from the 
> problem, and ask
> yourself what problem you're trying to solve via this 
> multiplexing.  You
> already said you didn't want to use tunneling, but at the 
> same time you gave us
> insufficient information to know if SMPP or anything similar 
> is applicable to
> your problem. With the information you gave, it's likely many 
> will fear to give
> you any really useful answers for fear of sending you in a 
> totally useless
> direction.
> 
> For all I know, HTTP pipelining may be a solution to your 
> problem - in that
> scenario, you have in-flight packets for multiple HTTP requests (read
> "subscribers") active at the same time.  On the other hand, 
> although it meets
> the requirements you stated, it's almost certainly not the 
> right answer.  But
> not knowing what problem you're trying to solve, it's hard to say.
> 
> Basically, you need to make sure that what you have in your 
> hand is a nail
> rather than a screw *before* you start selecting hammers....
> 
>

---

From: [email-masked]
Date: Sun, 25 Jan 2004 12:54:45 -0500

> and extract the subscriber mobile number.

It's tempting to suggest using IPv6 tunelling, and sorting out whos packets
are whose by inserting the subscriber info in the low-order 64 bits.

For that matter, aren't many mobile solutions IPv6 ready (at least in Japan,
which seems to have more of a clue about this than the US)?

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 25 Jan 2004 23:55:59 +0100

> are whose by inserting the subscriber info in the low-order 64 bits.

I would love to see the neighbor discovery (~= ARP for the 
v6-challenged) for such a solution. Not to mention that you can't run 
TCP that way.

But why use TCP in the first place? If this stuff is small enough to 
fit in a single IP packet, it makes much more sense to use UDP: no 
multiplexing problems. If reliability is needed it gets more complex, 
but some kind of RTP-like protocol makes more sense here than TCP.

---

From: jfcm <[email-masked]>
Date: Sun, 25 Jan 2004 21:29:02 +0100

>are whose by inserting the subscriber info in the low-order 64 bits.

That would make the solution dependent from the IPv6.001 numbering plan only.
jfc

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sun, 25 Jan 2004 21:54:47 -0600

The SMPP protocol really is a tunnelling protocol - one set of
endpoints is subscriber-to-subscriber, the other is server-to-server,
in this case, SMSC-to-ESME.

Since the subscriber-to-subscriber endpoints can use IP endpoint
addressing, ISDN endpoint addressing, or a mixture of IP and ISDN
addressing, it sounds like you really want to tunnel, but your inner
addressing is just strange.

Can you tell us any more about what you're trying to do?

Spencer

----- Original Message ----- 
From: "Haim Rochberger" <[email-masked]>
To: <[email-masked]>; "Haim Rochberger" <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, January 25, 2004 11:20 AM
Subject: RE: packets of multiple users sent over the same TCP/IP
session

> _______________________________________________
> This message was passed through [email-masked],
which is a sublist of [email-masked]. Not all messages are passed.
Decisions on what to pass are made solely by IETF_CENSORED ML
Administrator ([email-masked]).

---

From: Dave Crocker <[email-masked]>
Date: Sun, 1 Feb 2004 09:47:09 +0900

Haim,

HR> SMPP is a good example to what I am looking for, and I am trying to see if
HR> other
HR> protocol foreseen in the future (or past) have the same characteristics:

RFC1692, Transport Multiplexing Protocol, was designed for the
operation you appear to be describing.

As long as you have access to the necessary bits of protocol software
in the stack, it's a simple, flexible and efficient mechanism.

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>