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

From: "Brian Stucker" <[email-masked]>
Date: Tue, 20 Nov 2001 17:25:13 -0600

Ok, you've really got me confused now. I even went off to RFC-0760 (IP) and
RFC-0768 (UDP) to make sure that I wasn't off in the weeds. Even bis-05 SIP
talks
about MTU problems. I don't think I'm off in the weeds, but I see what
you're referring to.

I now see what you're getting at with the 64k size (maximum datagram size),
but
since IP makes no guarantee that any particular packet reaches it's
destination, it's
really IP that is the problem. I see what you're getting at with the UDP
packet
being fragmented to the IP next-hop MTU size, but that means that portions
of the UDP
packet may go missing and unknown since IP doesn't do anything to ensure
that any
particular datagram makes it to the destination.

What's worse, is popular operating systems such as Microsoft Windows (with
the possible exception of XP) specifically drops any datagram exceeding the
MTU value until it receives an ARP response for the first datagram (thus
guaranteeing it to drop all of the portions of the UDP packet, except for
the very last one:
http://support.microsoft.com/support/kb/articles/q233/4/01.asp).

Which brings me back to my original question, and I hope I'm not seen as
wasting time with this. Given if a UDP packet that exceeds the maximum MTU
size will be fragmented, and that the IP layer does not guarantee that any
particular datagram gets to it's destination (thus creating a need for
retransmissions), or that the pieces will arrive in any particular order, is
it acceptible to send multiple NOTIFY messages in order to packetize the
message body for transport over UDP in a more reliable method based on an
expected MTU size (ala RFC-1161). That's all I'm asking...

Perhaps you could expound on the issues this would create? I don't see any
difference in allowing multiple state agents to report pieces of the
resource state being watched as different from having one state agent report
the resource state in pieces.

The gain in doing so is to help alleviate issues that arise with very common
NAT/firewall implementations, where solving these issues with TCP or a
similar protocol is not possible. Or, alternatively, can you give a
mechanism for traversing a NAT to deliver a NOTIFY of any given length,
without using TCP?

Cheers,

Brian Stucker
Nortel Networks

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, November 20, 2001 4:17 PM
To: Stucker, Brian [NGB:B635:EXCH]; adam.roach; simple
Cc: Nava, Alex [NGC:B634:EXCH]; Sollee, Patrick [NGC:B680:EXCH]
Subject: RE: Question regarding NOTIFY messages using UDP.

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

---

From: [email-masked]
Date: Tue, 20 Nov 2001 17:49:38 -0600

talks
>about MTU problems.

It makes a recommendation. If fragmentation were really a problem, SIP would
mandate behavior. As it is, it's just trying to raise awareness of some of
the related issues (like the two I discuss in a previous mail).

>I don't think I'm off in the weeds, but I see what you're referring to.
but
destination, it's
packet
>being fragmented to the IP next-hop MTU size, but that means that portions of
the UDP
>packet may go missing and unknown since IP doesn't do anything to ensure that
any
>particular datagram makes it to the destination.

That's a problem even when you don't exceed the MTU. That's why
SIP retransmits requests.

There's a timer for reconstitution of the packet, sequence numbers,
a checksum, and all sorts of goodies in the UDP fragmentation to make
sure that it works. It's unreliable (but in an all-or-nothing sort
of way, just like all UDP datagram transmissions) but it works. All
you need is a mechanism to retransmit datagrams until they are
acknowledged, and SIP provides such a mechanism.

>What's worse, is popular operating systems such as Microsoft Windows
>(with the possible exception of XP) specifically drops any datagram
>exceeding the MTU value until it receives an ARP response for the first
>datagram (thus guaranteeing it to drop all of the portions of the UDP
>packet, except for the very last one:

I have two reactions to this:

1. Are you *seriously* proposing that we add provisions in the
   protocol to work around Microsoft's buggy IP implementation?

2. Even with this special little Microsoft bug, it all works.
   The first transmission of a UDP packet to a host might get
   lost; however, this first transmission will load the ARP cache
   for the destination, and the subsequent retransmissions will
   progress as normal.

I'm not arguing against your solution. I'm pointing out that
the "problem" you are trying to solve is not a problem. It might
be an inconvenience in corner cases, but it's not a problem.

/a

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