Subject: [Megaco] Segmentation Package Timer Questions

From: "Michael Dell" <[email-masked]>
Date: Fri, 8 Dec 2006 14:26:45 -0000

Hi there
 
I've been looking into designing support for the Segmentation Package
defined in annex E.14 of H.248.1 v3, and I think that there are some
areas of ambiguity in the specification which I'd like to clarify.
 
1.  The description of the package indicates that it is only for use on
non-segmenting transports.  This would suggest that it should not be
used over TCP.  However, as has been noted previously on this list,
whilst TCP itself doesn't impose a message size limit, the use of the
TPKT header in running Megaco over TCP imposes a maximum message size of
65535.  Would an implementation be non-conformant if it chose to use the
segmentation package to segment responses such that they fit within this
limit?  If so, should a receiving device expect to receive response
segments over a TCP connection?
 
2.  The specification isn't clear about whether the requester or the
responder is responsible for re-sending messages.  Since the
specification does not explicitly say that normal resend procedures do
not apply, I think that the correct behaviour should be as follows:

*	Device A sends a request, and starts its resend timer. 
*	Device B receives the request,  and starts sending response
segments. 
*	Device A receives some response segments, and sends
acknowledgements for them. 
*	Device A's resend timer pops before all response segments are
received.  Device A resends the request, and device B resends only those
segments which it has not received acknowledgements for. 
*	Device A receives a response segment with the END token.  It
starts a separate timer for this - the segmentation timer.  It is
expected that the segmentation timer duration is significantly shorter
than the resend timer. 

	*	Should the resend timer be stopped at this point?

*	If all pending message segments are received, the resend and
segmentation timers are stopped. 
*	If the segmentation timer pops, Device A sends a 459 error,
listing the segments it has not received. 

	*	The specification does not indicate what is expected of
device B here.  It could either resend the missing segments, or give up.
If it resends the missing segments, then what was the value of Device A
sending individual acknowledgements for segments it did receive?  Not
really clear to me in this model what the value of sending this error
is.

However, an alternative interpretation of the specification could be as
follows.  Note that this interpretation will not interoperate with that
above in some error conditions, which is why I'd like clarification from
the list.

*	Device A sends a request, and starts its resend timer. 
*	If the resend timer pops, Device A resends the request. 
*	Device B receives the request, and starts sending response
segments.  It starts a resend timer for each segment. 
*	When device A receives the first response segment, it cancels
its resend timer. 
*	Device A sends acknowledgements for each response segment. 
*	If any of Device B's segment resend timers pop, it resends that
segment.  The timer for each segment is cancelled when the
acknowledgement is received. 
*	If Device A receives a duplicate response segment, it resends
the acknowledgement for that segment. 
*	When Device A receives a response segment with the END token, it
starts the segmentation timer if it has any missing segments.  This is
cancelled if the missing segments arrive. 
*	If the segmentation timer pops, then Device A gives up on this
request, and sends the 459 error to device B to tell it to give up
sending response segments.  

	*	In this case, its not clear what the value of specifying
which segments were missing is.

Could the list please comment on whether either of the above models is
the intended one, and if not, fill in some of the details of how missing
segments and resends should be handled when segmentation is occurring?
 
Regards
 
Mike Dell
_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco