Subject: Buddy Lists and UDP max MTU size

From: [email-masked]
Date: Wed, 30 Jun 1999 10:37:14 +0530

Hi,
I have a question on SIP message exceeding MTU size.

My interpretation of Section 1.5.2 of RFC 2543 which states that UDP
datagrams should not exceed > MTU was that
all SIP messages must e wholly contained in one Datagram each.

Now, to implement Buddy Lists, Im returning a list of Registered Users when
a user sends a REGISTER. However, this will result in a very high
possibility of size > 1500.
There does not seem to be any way in the RFC which talks about breaking a
SIP packet across UDP datagrams. So currently Im using my own scheme to
correlate - which is not standard.

So my basic question is, is there a standard way which will allow a SIP
message to be transferred acrtoss multiple datagrams ?

Thxx
Regds
Arjun

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 30 Jun 1999 02:46:17 -0400

> all SIP messages must e wholly contained in one Datagram each.

No, it does not say that they should not exceed that MTU. In many cases
the UA won't know the path MTU.

> message to be transferred acrtoss multiple datagrams ?

First off, a UDP datagram can be bigger than 1500. It can be as large as
65535 bytes. Now, likely if its bigger than 1500, it gets fragmented at
the IP layer; but its still delivered in one piece to the receiver if
all its parts arrive. Not ideal, but it means a registrar CAN send
packets larger than 1500 bytes.

If the packets are really big, use TCP. If the registrar has a list of
contact addresses which is too long, it should redirect the calling
party to try TCP:

300 Too Big
Contact: sip:registrar.com;transport=tcp

The calling party can then re-register with TCP.

For normal SIP operation (not the buddy list concept described in a
separate draft), the likelihood of a registration response exceeding an
MTU is quite small. The only issue I see is for UDP only clients
(typically non-PC's) which register an address also being registered by
other devices. In that case, the response to the register could possibly
be longer than the UDP-only client expects. If it should happen to be so
long that TCP is required, the UDP-only device will never be able to
register. I see several potential solutions to this:

1. a registrar cuts off the list of Contact addresses in the 200 OK if
it becomes too big, rather than redirecting to TCP
2. a registrar only returns those Contact headers in the response whose
URI's appeared in Contact headers in the request
3. we add some kind of field which tells the server that TCP is not
supported, and to send the response via UDP

(3) is actually orthogonal to (1) and (2), and could be used to
effectively signal whether (1) or (2) should be used. 

Again, I should emphasize that the likelihood of fragmentation for
normal SIP operation is nearly nil.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen

---

From: "Klaus H. Wolf" <[email-masked]>
Date: Wed, 30 Jun 1999 13:38:21 +0200

> message to be transferred acrtoss multiple datagrams ?

Please do not make the buddy list-mistake again. 

I know the common thinking on presence and notifications is very much biased
by ICQ and AIM. But sending a buddy list to a single server is wrong. This
limits the system to a single server which is good for Mirabilis/AOL but not
for the public. It makes an additional effort necessary to cascade servers, if
buddies are in
different domains. 

Rather subscribe for 'online-status' (or whatever property) directly at each
user's presence server. In short: The buddy list is a list of users. User
names are URLs. The server addressed depends (as usual) on the host part of
the user name. Do not send the entire list to a single server. 

This answers the original question of this thread: Packets won't exceed the
MTU. 

I would like to make you aware of an internet draft I recently posted for the
next IETF meeting: http://www.ietf.org/internet-drafts/draft-wolf-pms-00.txt
Chapters 2.4 and 3.4

-- 
Klaus H. Wolf                                   Voice: +49 (731) 502 4145
Distributed Systems Dept.                     Ethernet: 08:00:20:12:2a:01
University of Ulm                          Cobrow: http://www.cobrow.com/
89069 Ulm, Germany     Live: http://www.cobrow.com/pages/people/wolf.html

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 30 Jun 1999 10:28:08 -0400

> for the public. It makes an additional effort necessary to cascade servers, if

No disagreement here. Henning and I put together a draft on using SIP as
the basis for presence:

http://search.ietf.org/internet-drafts/draft-rosenberg-sip-pip-00.txt

The basic idea is that the SIP server for a domain is also a natural
place to handle subscriptions for users in that domain. The SIP REGISTER
method conveys the "callability" of a particular user at a terminal, so
that a SIP server already has the information it needs to handle
subscriptions. If I want to subscribe to "[email-masked]", I would
use the same mechanisms as regular SIP to find the SIP server handling
subscriptions for this user. 

In this case, I would agree that the number of terminals (i.e.,
sip:[email-masked] and
sip:[email-masked]) associated with a particular
address will generally be small and a large NOTIFY message is quite
unlikely.

People interested in presence, instant messaging, and buddy lists might
want to check out the impp working group in the apps area. They are
right now finishing up their requirements work and will soon be moving
on to architectures and protocols.

-Jonathan R.