Subject: RE: [SIP] Multi-message UDP datagrams

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 26 Oct 2000 04:28:31 -0400

A few comments here.

First off, on the other thread about new-fangled way to do content-lengths -
no way. As Henning has pointed out, its way too late. Plus, there is proof
points that what we have now works fine. The mechanism is the one used by
both SIP and HTTP, and there are tons of clients and servers, thin and fat,
for both of these, and they work just fine. 

So, we are back to the original issue - should multiple SIP messages per
datagram stay or go. Sean is arguing here that it should stay because its
low hanging fruit. I would argue that "COULD" is different from "SHOULD".
That is, even if this were easy, if there is no reason or need, its not
worth it. Its simply yet-another-thing to test, to interoperate, to cerify
correctness, and to worry about. So, I would argue that it should stay only
if someone can give a good reason why it should.

The only mention of a reason to date has been to save overhead. This,
however, is a bogus argument. The overhead of the UDP/IP headers compared to
the size of the SIP message is tiny. Multiple messages in one datagram has
an almost negligible savings for the vast majority of messages. Thus, I do
not see this as a valid argument.

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

> -----Original Message-----
> From: Sean Olson [mailto:[email-masked]]
> Sent: Monday, October 23, 2000 3:31 AM
> To: Vijay K. Gurbani
> Cc: Jonathan Rosenberg; 'Piotr S. Kossowski'; [email-masked]
> Subject: Re: [SIP] Multi-message UDP datagrams
> 
> 
> I would strongly disagree with the complexity issue. You need 
> to know where the
> end of a
> SIP message is. What happens if you receive garbage at the 
> end of a UDP datagram?
> If you are going to take the time to deal with 
> Content-Length: or multipart/*,
> then you've
> gone 99% of the way to supporting multiple messages in a 
> single UDP datagram.
> Easy cheesy! This is not that complex.  I would remove line 
> folding before I
> messed
> with this. (Not that I'm suggesting we do this)
> 
> --
> Sean Olson <[email-masked]>
> 
> "Vijay K. Gurbani" wrote:
> 
> > Jonathan Rosenberg wrote:
> > >
> > > It was my view that receiving multiple messages in a 
> single datagram was the
> > > same as if they were received in separate datagrams. In 
> other words, there
> > > was no requirements for ordering or completion. The 
> result of that was a
> > > simplification in the implementation of handling this 
> case; UDP works just
> > > like TCP. Imposing transactional requirements adds 
> significant burden. I'd
> > > rather not do that unless there was serious requirements 
> or needs here.
> > >
> > > In fact, I would argue that multiple messages per 
> datagram might be
> > > something to consider for removal. I've never seen it 
> used. I'm not sure
> > > what the benefit is, in reality. There is little byte 
> savings, and its just
> > > more complexity that is really needless.
> > >
> > > Lets simplify, not complicate.
> > [...]
> >
> > For whatever it is worth, I agree.  In the bakeoff scenarios, I have
> > never
> > seen a SIP entity send multiple messages in the same datagram.
> >
> > Regards,
> >
> > - vijay
> > --
> > Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
> > Internet Software/IN Architecture Group
> > Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., 
> Rm 1A-413
> > Naperville, Illinois 60566     Voice: +1 630 224 0216   
> Fax: +1 630 713
> > 0184
> >
> > _______________________________________________
> > SIP mailing list
> > [email-masked]
> > http://lists.bell-labs.com/mailman/listinfo/sip
> 

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Sean Olson <[email-masked]>
Date: Thu, 26 Oct 2000 12:26:55 +0200

I'm perfectly happy with the removing this from SIP. I was simply stating that
the
"complexity" of multiple SIP messages in a UDP datagram was
not a strong argument against supporting it. Testing, interoperability,
lack of utility, etc. ARE good arguments against supporting it.
The complexity is comparable to the complexity of supporting
TCP (from a parsing point of view).

/sean

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Thu, 26 Oct 2000 10:00:24 -0400

I agree. It is also one of those features where bugs are hard to catch.
For example, one could easily get into a situation where the receiver
ignores the second request in a packet, causing a retransmission as a
single-request-per-UDP packet. This "works", but now every request
generates two packets.

Having one request or message per UDP packet is also by far the dominant
mode of operation for Internet protocols. I'm not aware of any protocol
that doesn't follow this basic operational rule.

Remember that we will have to find and test two independent
interoperable implementation for every feature to progress SIP to Draft
Standard. The more features, the longer this will take. Maybe we should
institute a rule that every individual or organization that proposes a
new feature will take it upon them to make this effort of finding and
documenting interoperability. Indeed, it would be very nice if somebody
or some group of volunteers could step forward to gather a feature check
list and make this available during the bake-offs (bake-off is a
registered trademark of the Pillsbury company and used here without
permission).

For systems with lots of messages exchanged, it is probably better to
use TCP or SCTP, as that provides faster loss recovery for high-rate
streams and, with TLS, easier security. I doubt that implementations
will actually go through the trouble of gathering up messages for joint
delivery, with all the timer hassles that implies.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs