Another point to consider is when to use which transport:

for Annex G: small/fast messages should be sent over UDP (e.g. the Access family) large/slow messages should be sent over TCP (e.g. information push/pull) ultimately this is an implementation + network environment issue.

for Annex E, I really don't see this as an issue - 225 messages are small (we did specify PER for a purpose) and far between, so the follow the small/fast category.

- gur

-------- On 05/05/99 04:08 PM GMT Andrew Draper Andrew.Draper@MADGE.COM wrote:

At 09:35 1999-05-04 +0200, ETO wrote:

When an Annex G message will exceed max packet size (typically a DescriptorConfirm) on UDP, a Reject might be sent, and the session is repeated on TCP.

But, isn't our PDU size on TCP also limited? When using TPK,

the max pdu

size is 65k too, as seen in RFC-1006....

I don't think this is a problem for Annex G.

First, a sensible implementation is probably sending DescriptorRequests over TCP anyway since it expects a large (well larger than MRU) answer anyway so the UDP step described above won't happen (only AccessRequest and ValidationRequest is likely to be sent over UDP).

Secondly, the only message likely to run into the maximum message size limit is the DescriptorConfirm (if a descriptor is more than 64K). I don't expect anyone to have a descriptor of 64K or more, but if they do it can be broken down into multiple descriptors, and each one transmitted separately.

For call signalling over annex E the message size limit isn't a problem either. Annex E will be transmitting the same call signalling messages as would be sent over TPKT over TCP, so messages of more than 64K aren't allowed (since they wouldn't fit within TPKT), even if anyone can create a plausible one.

Regards,

Andy

-- Andrew Draper -- Principal Development Engineer -- WAVE Software Madge Networks, Wexham Springs, Framewood Road, Wexham, Berks, UK. mailto:adraper@madge.com = = = = = = = = = phone:+44 1753 661329 pgp fingerprint 8776 1F5F DD1B F37E BEF7 1E52 924D F6B7 34CB EFA9