Subject: RE: [Megaco] TPKT value for H.248 over TCP

From: "Kevin Boyle" <[email-masked]>
Date: Wed, 14 Jan 2004 13:24:37 -0500

I was under the impression that TCP segmented large packets automatically.
Is that not the case?
 
Kevin

  _____  

From: Sampath Komanduri [mailto:[email-masked]] 
Sent: Tuesday, January 13, 2004 12:25 PM
To: 'MEGACO list'
Subject: RE: [Megaco] TPKT value for H.248 over TCP

Could the author of Annex D pls. respond?
 
Thanks,
Sampath

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Sampath Komanduri
Sent: Tuesday, January 06, 2004 8:16 PM
To: 'MEGACO list'
Subject: [Megaco] TPKT value for H.248 over TCP
Importance: High

Hi List,
I am not sure if this question was already raised in the list. If it was,
pls. point me to the discussion and the consensus.

According to ANNEX D of H.248.1 protocol, "TPKT, according to
<http://www.faqs.org/rfcs/rfc1006.html> RFC 1006, SHALL be used to delineate
messages within the TCP stream". RFC 1006 limits the size of TPDU to 65524.
Replicating the relevant text here for convenience:
 
***************************************************
     "A TPKT consists of two parts:  a packet-header and a TPDU.  
      The format of the header is constant regardless of the type of packet.
      The format of the packet-header is as follows:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      vrsn     |    reserved   |          packet length        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      where:

      vrsn                         8 bits

      This field is always 3 for the version of the protocol described in
this memo.

      packet length                16 bits (min=7, max=65535)

      This field contains the length of entire packet in octets, including
packet-header.
      This permits a maximum TPDU size of 65531 octets.
      Based on the size of the data transfer (DT) TPDU, this permits a
maximum 
      TSDU size of 65524 octets."
*********************************************************
 
This causes an issue. Based on the wildcard level of Audit and the
descriptors involved, this size could easily exceed 64K size (especially if
MG and MGC are using Long text format and white spaces in the messages). In
few cases, it is possible to return an error code (533: Response exceeds
maximum transport PDU size).
However, in some cases returning 533 is not an option. 
Consider for example the following scenario: After an association is
DISCONNECTED, MGC may want to get the list of non-null contexts on the
gateway using the following command (pls. ignore if there is any mistake in
the message and reply construct):
 
!/1 [10.102.2.201]:4000 T=3700003{C=*{AV=ROOT{AT{}}}}
!/1 ABCD_MG P=3700003{C=1{AV=C{*}},C=2{AV=C{*}},C=3{AV=C{*}}, ....and so on}

In the best case (i.e. no white-space, no audit descriptor and short
format), this allows for an MG to have only 5000 active contexts on the
card. Anything more (or any variation in the audit command) will reduce the
number of active contexts that an MG can have even with TCP as the transport
option.
Responding with 533 is not an option here since that would leave MG-MGC in
state from where there is no elegant way out (at least from H.248 protocol).
 
How do the gurus' on list suggest we solve this issue? Couple of ideas that
come to mind are:

1.	Define a Bulk-Audit Package/scheme: As was done for MGCP, define a
Bulk-Audit package/scheme especially with support for       
    RangeWildcard = "[" NumericalRange *( "," NumericalRange ) "]" and
    NumericalRange     = 1*(DIGIT) [ "-" 1*(DIGIT) ].
    This will certainly reduce the cases and scenarios when MG/MGC will run
into the issue under discussion but may not eliminate it. 

2.	Add more information on W- Audit support in the protocol. 

3.	Introduce RFC 1006 modification (with version field 4) such that
"packet length" of packet header in TPKT is 32 bits as opposed to 16 bits. 

4.	Combination of the above schemes. 

5.	Anything else?

Pls. advice on how this problem can be solved?

Thanks,
Sampath

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: "Raju" <[email-masked]>
Date: Wed, 14 Jan 2004 12:35:21 -0600

Kevin,

That's correct.
But to find the beginning and end of packets H.248 uses TPKT Version 3 (RFC
1006)
which has a header (4 bytes) followed by the H.248 msg. The TPKT  header
has 2 byte length field, using which we can only send a h248 msg of size <
65531 bytes
(the TPKT two bytes length includes the TPKT header length of 4 bytes).

Thanks
Raju

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Kevin Boyle
> Sent: Wednesday, January 14, 2004 12:25 PM
> To: [email-masked]; 'MEGACO list'

---

From: "Raju" <[email-masked]>
Date: Wed, 14 Jan 2004 12:35:21 -0600

Kevin,

That's correct.

Thanks
Raju

---

From: "Sampath Komanduri" <[email-masked]>
Date: Wed, 14 Jan 2004 10:49:09 -0800

Kevin,
The issue is not with TCP itself. The problem stems from the basis that
MEGACO is an ISO application which is designed to run over the OSI stack
(7 layer stack), not the TCP/IP stack (5 layer stack, no session or
presentation layers).  In order to make ISO protocols/applications
capable of running over TCP, a "pseudo-header" (or TPKT) in RFC1006 was
created.  This allowed support for the additional layers not found in
the TCP/IP stack.  This pseudo-header is found in the application layer
of the TCP/IP stack and has no correlation to the functions preformed at
the TCP layer.  Applications that were designed for the TCP/IP stack do
not require this pseudo-header (ex. HTTP or FTP).  These applications
use other means for delimiting messages (read RFC959 sections 3.4.1 &
3.4.2 for how FTP delimit messages) and as you know have no PDU size
limitations (FTP can handle Megabyte file transfers).

This essentially restricts the maximum transport protocol data unit
(TPDU) size that can be transferred to TCP layer by Megaco application
to 65524 octets. TCP, based on the MTU and PMTUD, will segment and
re-assemble the TPDU (max. 65524 octets) at transmiting and recieving
end.
 
I was asking if we authors of H.248 Annex D can address this issue in
the standard itself. One way to do it is bump up the "version" field in
TPKT to 4 and use 4 octets to represent the TPDU size.
 
Thanks,
Sampath

-----Original Message-----
From: Kevin Boyle [mailto:[email-masked]] 
Sent: Wednesday, January 14, 2004 10:25 AM
To: [email-masked]; 'MEGACO list'
Subject: RE: [Megaco] TPKT value for H.248 over TCP

I was under the impression that TCP segmented large packets
automatically.  Is that not the case?
 
Kevin

  _____  

 
Thanks,
Sampath

-----Original Message-----

Hi List,
I am not sure if this question was already raised in the list. If it
was, pls. point me to the discussion and the consensus.

According to ANNEX D of H.248.1 protocol, "TPKT, according to
<http://www.faqs.org/rfcs/rfc1006.html> RFC 1006, SHALL be used to
delineate messages within the TCP stream". RFC 1006 limits the size of
TPDU to 65524. Replicating the relevant text here for convenience:
 
***************************************************
     "A TPKT consists of two parts:  a packet-header and a TPDU.  
      The format of the header is constant regardless of the type of
packet.
      The format of the packet-header is as follows:

        0                   1                   2                   3

      where:

      vrsn                         8 bits

      This field is always 3 for the version of the protocol described
in this memo.

      This field contains the length of entire packet in octets,
including packet-header.
 
This causes an issue. Based on the wildcard level of Audit and the
descriptors involved, this size could easily exceed 64K size (especially
if MG and MGC are using Long text format and white spaces in the
messages). In few cases, it is possible to return an error code (533:
Response exceeds maximum transport PDU size).
However, in some cases returning 533 is not an option. 
Consider for example the following scenario: After an association is
DISCONNECTED, MGC may want to get the list of non-null contexts on the
gateway using the following command (pls. ignore if there is any mistake
in the message and reply construct):
 
!/1 [10.102.2.201]:4000 T=3700003{C=*{AV=ROOT{AT{}}}}
!/1 ABCD_MG P=3700003{C=1{AV=C{*}},C=2{AV=C{*}},C=3{AV=C{*}}, ....and so
on}

In the best case (i.e. no white-space, no audit descriptor and short
format), this allows for an MG to have only 5000 active contexts on the
card. Anything more (or any variation in the audit command) will reduce
the number of active contexts that an MG can have even with TCP as the
transport option.
Responding with 533 is not an option here since that would leave MG-MGC
in state from where there is no elegant way out (at least from H.248
protocol).
 
How do the gurus' on list suggest we solve this issue? Couple of ideas
that come to mind are:

1.	Define a Bulk-Audit Package/scheme: As was done for MGCP, define
a Bulk-Audit package/scheme especially with support for       
    RangeWildcard = "[" NumericalRange *( "," NumericalRange ) "]" and
    NumericalRange     = 1*(DIGIT) [ "-" 1*(DIGIT) ].
    This will certainly reduce the cases and scenarios when MG/MGC will
run into the issue under discussion but may not eliminate it. 

3.	Introduce RFC 1006 modification (with version field 4) such that
"packet length" of packet header in TPKT is 32 bits as opposed to 16
bits. 

5.	Anything else?

Thanks,
Sampath

---

From: "Sampath Komanduri" <[email-masked]>
Date: Wed, 14 Jan 2004 10:49:09 -0800

Kevin,

 
Thanks,
Sampath

-----Original Message-----
From: Kevin Boyle [mailto:[email-masked]] 
Sent: Wednesday, January 14, 2004 10:25 AM
To: [email-masked]; 'MEGACO list'
Subject: RE: [Megaco] TPKT value for H.248 over TCP

Kevin

  _____  

 
Thanks,
Sampath

-----Original Message-----

Hi List,

        0                   1                   2                   3

      where:

      vrsn                         8 bits

 

 

5.	Anything else?

Thanks,
Sampath

---

From: Troy Cauble <[email-masked]>
Date: Wed, 14 Jan 2004 15:12:11 -0500

> TPKT to 4 and use 4 octets to represent the TPDU size.

Using 4 octets has a limit as well.
Better avoid that too.

-troy

---

From: Troy Cauble <[email-masked]>
Date: Wed, 14 Jan 2004 15:12:11 -0500

-troy

---

From: "Raju" <[email-masked]>
Date: Wed, 14 Jan 2004 14:32:50 -0600

Troy,

I doubt if we ever reach 32-bit length range (32 Gaga bytes in
one single h248 msg?! if a GW ever needs to send such a huge msg
then  there must be some other big problems in dealing with
such a huge msg!!).

Besides that, if we all want, we can even have a 8-byte length
field in TPKT version 4 (which can hold trillions o f bytes).

Kevin,
Can you please resend the proposal you made to overcome this 64k
limitation.

Thanks
Raju

> Troy Cauble
> Sent: Wednesday, January 14, 2004 2:12 PM
> To: [email-masked]
> Cc: 'Kevin Boyle'; 'MEGACO list'
> Subject: Re: [Megaco] TPKT value for H.248 over TCP
>
>
> Sampath Komanduri wrote:
>

---

From: "Raju" <[email-masked]>
Date: Wed, 14 Jan 2004 14:32:50 -0600

Troy,

Kevin,

Thanks
Raju

---

From: Troy Cauble <[email-masked]>
Date: Wed, 14 Jan 2004 15:56:45 -0500

> Can you please resend the proposal you made to overcome this 64k

Well, I would have said the same for 64K, which was really my point.
It already seems like a hypothetical issue to me.

But I guess I work with smaller gateways than some people.

(Hi Raju!  Still employed I see!)

-troy

---

From: Troy Cauble <[email-masked]>
Date: Wed, 14 Jan 2004 15:56:45 -0500

-troy