Subject: [ANCP] Proposed text for fragmentation in base AQNCP specification

From: Tom Taylor <[email-masked]>
Date: Sun, 28 Mar 2010 12:50:18 -0400

The meeting agreed that there could be a case for using application-level 
message fragmentation in some circumstances even though ANCP uses TCP. Basically 
the argument is that breaking up large messages allows other messages, perhaps 
of greater urgency, to get through. I volunteered to provide text to cover this 
in the base specification. Not that GSMPv3 already provides for message 
fragmentation, so it is only a matter of documenting the GSMPv3 procedures.

First change: section 5, Result field. Add the following text:

More:

         Res = 0x05 - Set by message sender to indicate that the message,
         either request or response, has been segmented and that one or
         more additional segments will follow. See also the description
         of the I flag and SubMessage Number fields below.

Second change: section 5, replace existing "I flag" description with the 
following text:

I flag and SubMessage Number

    Since ANCP uses TCP as transport, message segmentation will normally
    be unnecessary. However, implementations MAY choose to segment
    very large messages (either requests or responses) so that other
    messages can be transmitted between segments.

    When the complete message is transmitted without segmentation, the
    sender MUST set the I flag and SubMessage Number both to the value "1".

    When a message is segmented, the GSMPv3 (RFC 3292) segmentation
    procedure MUST be applied. For all segments except the last one,
    the Result field MUST be set to More (0x5). The Result field for
    the last segment MUST be set as it would have been had the request
    or response been sent in a single message.

    When a message is segmented, the I flag for the first segment MUST be
    set (have value 0x1), and the value of the SubMessage Number field
    MUST be equal to the total number of segments (including the first)
    comprising the complete message. The I flag for each subsequent segment
    MUST be cleared (have value 0x0), and the value of the SubMessage Number
    field MUST be equal to the sequence number of this segment within the
    complete sequence, counting from 2 for the second segment.

Third change: section 5, Length field. Add the following sentence:

    When a message has been segmented, the Length field gives the length
    of the current segment only.

That last change is ambiguous in GSMPv3. Maybe the value should be the legth of 
the complete message instead. Comments are invited.

Tom Taylor

---

From: Sidd Aanand <[email-masked]>
Date: Tue, 30 Mar 2010 10:10:04 -0400

Tom,

Is there a need to add a capability that indicates whether the node is capable of handling fragmentation?

Sidd 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tom Taylor
Sent: Sunday, March 28, 2010 12:50 PM
To: [email-masked]
Subject: [ANCP] Proposed text for fragmentation in base AQNCP specification

The meeting agreed that there could be a case for using application-level message fragmentation in some circumstances even though ANCP uses TCP. Basically the argument is that breaking up large messages allows other messages, perhaps of greater urgency, to get through. I volunteered to provide text to cover this in the base specification. Not that GSMPv3 already provides for message fragmentation, so it is only a matter of documenting the GSMPv3 procedures.

More:

Second change: section 5, replace existing "I flag" description with the following text:

That last change is ambiguous in GSMPv3. Maybe the value should be the legth of the complete message instead. Comments are invited.

Tom Taylor
_______________________________________________
ANCP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ancp

---

From: Tom Taylor <[email-masked]>
Date: Tue, 30 Mar 2010 10:22:56 -0400

It's part of GSMPv3, so one can assume its implemented already.

---

From: Wojciech Dec <[email-masked]>
Date: Tue, 30 Mar 2010 17:01:53 +0200

Actually, while GSMPv3 was a base for ANCP, it's my understanding that
practically all implementations follow just the ANCP spec. As such, sequence
numbering is something that does not exist today, for anything but the
implementations following the mcast spec. The sequencing in the mcast spec
was intended to deal with ordered/sequenced command execution and the
ability to determine where an error occurred. That's quite different from
sequence numbering for fragmentation.

Taking a step back: GSMP's purpose for fragmentation was due to it being
design to run as a standalone transport protocol.
ANCP runs on TCP, and it's not quite clear to see why we should be trying to
solve effectively head-of-line blocking at the ANCP level, instead of opting
for a transport that already solves this (SCTP). Either way, an
ANCP-transport-adaptation layer needs to be introduced, and it would seem
better for it to be dedicated to adapting to other transports rather than
specializing in solving a TCP blocking problem. With this in view, it may be
that instead of solving the message-fragmentation aspect in the base ANCP
spec it would be better to direct the effort into an ANCP-new-transport
draft.

More comments/discussion is welcome.

-Woj. 

On 30/03/2010 16:22, "Tom Taylor" <[email-masked]> wrote:

>> message fragmentation in some circumstances even though ANCP uses TCP.
>> Basically the argument is that breaking up large messages allows other
>> messages, perhaps of greater urgency, to get through. I volunteered to
>> provide text to cover this in the base specification. Not that GSMPv3 already
>> provides for message fragmentation, so it is only a matter of documenting the
>> GSMPv3 procedures.
>> 
>> That last change is ambiguous in GSMPv3. Maybe the value should be the legth
>> of the complete message instead. Comments are invited.
>> 
>> Tom Taylor

---

From: Tom Taylor <[email-masked]>
Date: Tue, 30 Mar 2010 13:33:18 -0400

OK, I'm willing to back out the fragmetation-related text in the multicast 
extensions document. It just seemed like a good idea. We can see whether people 
need a different transport in the future before we bother to add a new one.

> More comments/discussion is welcome.
...