Hi, Avygdor,
We're very close (not that I have a ballot position, but :-) ...
Ah - in that case, I suggest that you delete the sentence "While this
mode of operation is not explicitly supported in the ANSI C12.22
standard, it MAY be made possible through mutual operating agreements".
You don't need to say this, and you're just calling the reader's
attention to an undesirable practice that MIGHT work - that's enough to
make some product managers say "oh, you can implement Uni-directional TCP
for this, and tell people to make it work". :-(
Ok. Will delete the text
"While this mode of operation is not explicitly supported in the ANSI
C12.22 standard, it MAY be made possible through mutual operating
agreements. The means by which nodes are configured to enact the
uni-directional use of TCP is not defined in this specification or in the
ANSI C12.22 standard; it is left for future consideration."
You actually deleted two sentences - I wasn't sure about asking you to
delete the second sentence, but if you're OK with it, I think that's fine.
3.4.2. Sending Large C12.22 APDUs Using UDP
When sending a large C12.22 Message via UDP, whereby the ACSE PDU
size exceeds the UDP datagram maximum data length (65527 bytes), the
initiating C12.22 IP Node SHALL segment the ACSE PDU in accordance
with ANSI C12.22 Datagram Segmentation and Reassembly algorithm, such
that each APDU segment fits within the UDP data field.
Spencer (minor): If you're matching something that's already deployed,
fine, but if you have an opportunity to set a lower bound than 65527
bytes for invoking application-level segmentation and reassembly, I'd
suggest thinking about that. Losing fragments means you retransmit the
entire IP packet (no surprise there), and more fragmentation means
you're taking up more reassembly buffers on NATs, if this protocol is
really intended to traverse the Internet...
This explains the upper limit that is imposed on to the Segmentation
Algorithm of ANSI C12.22 by the IP Network. When a node pushes data
above that size it must segment.
However, nodes may choose to segment a much lower limits (which may be
negotiated between peers by the C12.22 Protocol).
I'm not an expert in the application space where you're working, but if
it's anything like the open Internet, there are a lot of reasons to avoid
IP fragmentation when you can do so.
To name two, some NATs drop packets that don't have port numbers
(subsequent fragments don't), and when one fragment is lost for an
application that can't "lose" packets, the entire IP packet has to be
retransmitted. Assuming a 1500-byte-ish 802 link layer, you're saying
that applications don't have to worry until the Message size is bigger
than 65527 bytes - that's 44 fragments. If you've already lost one
fragment due to congestion, throwing 44 more packets onto the path seems
wrong.
You might wish to consider encouraging use of the C12.22 Protocol to
negotiate lower limits (probably at SHOULD strength), unless you're sure
that the current text won't lead to problems in your application space
(and that your application won't be used on the open Internet).
I see the problem. We are caught between a rock and a hard place.
Most payloads are very small (less than 100 bytes). The reason for the
number 65527 is to instruct the user not to trip on UDP.
The problem you indicate will need to be addressed in C12.22, since it
originates there and if it is a defect in C12.22 then it will be common
not just to IP but other transports that C12.22 may use as well.
I will bring this to the attention of ANSI SC17 and IEEE SCC31 (the
committees) for correction.
I understand. You documented the limit that is KNOWN to fail :-)
I'm understanding from our conversation that you might be communicating with
a C12.22 endpoint that won't negotiate downward before happily sending you
maximum-length UDP packets whether you wish they would or not...
Ralph - I might be pushing too hard on this one - could you provide
guidance?
Thanks again for the quick turnaround on this.
Spencer
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
