Re: Annex G & big messages (and TPKT and Annex E)
Douglas , Espen:
You are right, both TPKT and Annex E limit each segment within a message to a max of 64K bytes - and both allow you to aggregate - place multiple payloads, each sized at (or less) 64K in a single message - this is of course relevant only to Annex E over TCP (which is not really used as this time for anything).
I don't see this is a serious limitation - unless the information exchange between GKs is going to contain many pictures... seriously, you will need to divide up your large transactions into 64K segments.
If any of you think this is a real problem - speak up -
- gur
-------- On 05/04/99 09:15 AM GMT Douglas Clowes dclowes@OZEMAIL.COM.AU wrote:
No, I had reached the same conclusion - the packet size is, indeed, limited to 65K bytes. If the message size exceds the UDP MTU, it hould be sent by TCP. What I am still wondering is, will we exceed the 65K on TCP?
Subtly, this raises a similar question for Annex E which has the same limitation. Should Annex E have a larger size field, and Annex G use Annex E for a larger message size?
Does the TPKT size limitation affect anything else which uses it?
Douglas
At 09:35 1999-05-04 +0200, ETO wrote:
Hi all,
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....
Hope I'm wrong here.
Espen
I agree with Gur.
The TPDU in RFC1006 (TPKT) and the equivalent message in Annex E are "limited" (I don't think this is much of a limitation personally) to 64K bytes (65536 bytes). For Annex E, any message over 1500 bytes (actually 1500 bytes minus headers) must be sent over TCP since neither UDP nor Annex E (nor RFC 1006) inherently provide a fragmentation and reassembly mechanism.
Since Annex E is really only defined for H.225 transport this shouldn't be a problem.
Does anyone have an example of a real-world signaling message that exceeds 1500 bytes (much less 64K bytes)? How about an imaginary one (with probability of occuring greater than 0)?
I'd recommend that if you are transmitting messages larger than 64K bytes over Annex E or G that you re-evaluate the protocols (or the implementations) you are using. Neither Annex E nor G are intended for use as a general purpose Transport protocol over the Internet.
Chip
At 09:07 PM 5/4/99 +0600, Gur Kimchi wrote:
Douglas , Espen:
You are right, both TPKT and Annex E limit each segment within a message to a max of 64K bytes - and both allow you to aggregate - place multiple payloads, each sized at (or less) 64K in a single message - this is of course relevant only to Annex E over TCP (which is not really used as this time for anything).
I don't see this is a serious limitation - unless the information exchange between GKs is going to contain many pictures... seriously, you will need to divide up your large transactions into 64K segments.
If any of you think this is a real problem - speak up -
- gur
-------- On 05/04/99 09:15 AM GMT Douglas Clowes dclowes@OZEMAIL.COM.AU wrote:
No, I had reached the same conclusion - the packet size is, indeed, limited to 65K bytes. If the message size exceds the UDP MTU, it hould be sent by TCP. What I am still wondering is, will we exceed the 65K on TCP?
Subtly, this raises a similar question for Annex E which has the same limitation. Should Annex E have a larger size field, and Annex G use Annex E for a larger message size?
Does the TPKT size limitation affect anything else which uses it?
Douglas
At 09:35 1999-05-04 +0200, ETO wrote:
Hi all,
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....
Hope I'm wrong here.
Espen
-------------------------------------------------- Chip Sharp voice: +1 (919) 851-2085 Cisco Systems Consulting Eng. - Telco Reality - Love it or Leave it. --------------------------------------------------
participants (2)
-
Chip Sharp
-
Gur Kimchi