Subject: [Simple] RE: Question regarding NOTIFY messages using UDP.

From: "Brian Stucker" <[email-masked]>
Date: Tue, 20 Nov 2001 15:55:05 -0600

64kbyte? I thought the standard MTU size for a UDP packet was something on
the
order of 1500 bytes, that's significantly lower. Maybe we're talking about
two different things.

In the case that no previous presence document has ever been sent, or even
if the diff is greater than the MTU, you still run into a problem.
Therefore, the simplest, and most expedient solution (to me, where TCP or
the like can't be used very easily) would be to allow the message body in
the NOTIFY be "packetized" so that it can safely fit into a UDP MTU, and
sent in pieces instead.

Is this a horribly bad thing, or something that we can toy around with now?
Presence is going to encounter (hopefully) a lot of residential firewalls
that it'll have to contend with, where a connection-oriented transport
cannot be initiated or maintained easily by the network.

I'm not even convinced this is an events draft item to worry about, really.
I didn't notice anything in your draft that really precludes this behavoir.
Can it be included with a caveat emptor disclaimer?

Brian Stucker

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, November 20, 2001 3:34 PM
To: Stucker, Brian [NGB:B635:EXCH]; simple
Subject: RE: Question regarding NOTIFY messages using UDP.

Once your presence documents exceed 64 kbytes, this becomes a
problem. This seems extremely unlikely.

In the short term, I propose that you send complete presence
documents. As they become larger than the path MTU, you might
see a nominal increase in retransmissions, but I doubt it will
become unacceptable. (This is based on implementation
experience, not random guessing).

For the long term (post-sip-presence-RFC), you probably want to
toy around with defining a mechanism for sending state deltas,
as is described in the sip-events draft. I propose that you not
worry about this for now; there are more pressing issues.

/a

-----Original Message-----
From: Brian Stucker [mailto:[email-masked]]
Sent: Tuesday, November 20, 2001 3:19 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Question regarding NOTIFY messages using UDP.

Hi all,
I have a new question for the list...
In the case where a client can only use UDP to communicate with a presence
server, the size of presence messages gets quite large. Would there be a
problem introduced if the presence document were split up across multiple
NOTIFY messages (perhaps a few presence tuples at a time)? It would be one
PA
sending all of the pieces of the presence document, just instead of in one
NOTIFY, in many over a short period of time to avoid fragmentation issues.
The only issue I see is if a client sends a fetch subscribe, it might not
expect multiple NOTIFY messages, but from discussions about merging state
earlier it seemed there wasn't an issue with sending the presence document
in
parts, just that it needs to be aggregated before sending (which it still
would
be).
Thoughts?
Brian

---

From: [email-masked]
Date: Tue, 20 Nov 2001 16:17:01 -0600

This is a commonly misunderstood thing about MTUs. The IP layer
(either of your machine or of a router on the path of your
communications) will break up any large UDP packets into fragments
to make them fit in the next-hop MTU. Reassembly of fragmented
packets is performed at the receiver end -- once again, at the
IP layer.

Note that all of this is transparent to the application.

The recommendation to keep messages smaller than a path MTU
(or 1500 bytes, which is a reasonable guess) is to prevent
this fragmentation. The reasons to avoid fragmentation is
that it causes a nominal increase in the chance that a packet
is dropped (any missing fragment invalidates the whole packet),
and that it may consume additional (usually kernel) resources
at the receiving end as packets are being reconstituted.

Neither of these consequences is particularly dire, which is
why I proposed that we can address this problem later.

Technically, the draft as it's currently written *does* preclude
the behavior you propose. The current version gives packages
two choices:

1. Always send complete state
2. Send complete state in response to SUBSCRIBEs, and deltas
   in response to state changes.

Your proposal would be a third option -- one that opens up a
whole host of issues with little or no gain. Let's not waste
cycles discussing this.

/a

-----Original Message-----
From: Brian Stucker [mailto:[email-masked]]
Sent: Tuesday, November 20, 2001 3:55 PM
To: adam.roach; simple
Cc: Alex Nava; Patrick Sollee
Subject: RE: Question regarding NOTIFY messages using UDP.

64kbyte? I thought the standard MTU size for a UDP packet was something on the
order of 1500 bytes, that's significantly lower. Maybe we're talking about two
different things.
In the case that no previous presence document has ever been sent, or even if
the diff is greater than the MTU, you still run into a problem. Therefore, the
simplest, and most expedient solution (to me, where TCP or the like can't be
used very easily) would be to allow the message body in the NOTIFY be
"packetized" so that it can safely fit into a UDP MTU, and sent in pieces
instead.
Is this a horribly bad thing, or something that we can toy around with now?
Presence is going to encounter (hopefully) a lot of residential firewalls that
it'll have to contend with, where a connection-oriented transport cannot be
initiated or maintained easily by the network.
I'm not even convinced this is an events draft item to worry about, really. I
didn't notice anything in your draft that really precludes this behavoir. Can
it be included with a caveat emptor disclaimer?
Brian Stucker

_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple