Hi Erez,
Thanks for the note.
On Mon, 12 Jun 2023 21:14:17 +0200, Erez wrote:
> This is not the only standard that follows the market and existing
> products.
> It happens everywhere.
> I do not suggest to ignore standards,
> Only bear in mind that we can not rely on others to implement the
> standard to the letter.
> And that standards in many cases involve politics of many vendors,
> which lead to ambiguity by design and compromises.
Definitely. In the audio space where I work there are many examples of
this. I have seen how being first to market and having wide adoption can
end up turning "improper" implementations into a de facto standard.
Based on my reading of the archives, however, it does not sound like
there is a desire to support such impropriety when it comes to padding.
My original email was not meant to be a full endorsement of the current
implementation, but rather a justification for why it is technically
reasonable.
> Dylan. just one note.
> The IEEE 802.3 standard actually follows an already existing Ethernet
> protocol (Ethernet II).
To add to this observation, since PTP utilizes the Ethernet II
convention of using the length/type field in the frame as a type field
rather than a length field, the expressed requirement is for the upper
level protocol, in this case PTP, to have a mechanism for determining
the length of the encapsulated message, if it is relevant. I would argue
that the messageLength field was intended to be part of that mechanism
for PTP, but I also agree that the standard doesn't actually prescribe
its use. The mechanism currently in use is inference based on known
possible payload sizes and known minimum frame sizes. This generally
works, but it somehow feels less robust than using the messageLength
field. I would argue that the messageLength field should not be
considered redundant in the case of layer 2 links.
I will say that some of the discussions in the archives seem to
simultaneously talk about UDP and layer 2 transports in the same thread
which somewhat confused my attempt at understanding everyone's position.
>From my reading of IEEE 802.3, it doesn't sound like the standard wants
to preclude future revisions from defining a larger minFrameSize
parameter. After all, the minFrameSize parameter is defined per MAC data
rate (IEEE 802.3 section 4.4.2). All currently defined MAC data rates
use a minFrameSize of 64 octets, but it seems conceivable that in the
future a faster data rate could require a larger minFrameSize. If this
happened and the parameter grows beyond 67 bytes, the current
implementation would discard those messages as bad messages.
Given that a feature of the Linux PTP Project is a "modular design
allowing painless addition of new transports", I think there either
should be clarification in the form of documentation or code comments of
what is expected to be delivered from the transport layer in terms of
payload length, or the transport independent layer should be able to
handle receive buffers with various amounts of trailing padding.
If it makes sense to go down the path of requiring the transport layer
to deliver specifically sized messages to the transport independent
layer, then I would argue that any transport that does not explicitly
communicate the size of its payload should read the PTP header and use
the messageLength field to deliver only the relevant bytes to the upper
layer.
Finally, I wanted to comment on an exchange that I read before.
On Fri, Feb 01, 2019, Richard Cochran wrote:
> On Thu, Jan 31, 2019 at 04:22:20PM +0000, Geva, Erez wrote:
> > For me, the only question is, if the Ethernet frame does have
> > padding and the PTP frame is proper.
> > Is there a problem?
>
> Yes, there is a problem. The length of the messages affects their
> delay through network equipment. The PTP event messages are carefully
> designed to all have the same length. You simply should not go
> tacking random stuff onto the end of frames.
While Richard's comment here may be true for messages that are forwarded
through network equipment, not all profiles actually allow this to
happen. For example, within 802.1AS there are only PTP Relay Instances
and PTP End Instances. Frames are not "forwarded" through network
equipment. Rather, they are "relayed" with corrections for their exact
residence time in said equipment. 802.1AS defines the message timestamp
points precisely. For example, the media-dependent layer specification
for full-duplex point-to-point links requires the following.
802.1AS-2020 section 11.3.9 - Event message timestamp point:
The message timestamp point for a PTP event message shall be the
beginning of the first symbol following the start of frame
delimiter.
Since the message is timestamped at the beginning of the frame,
superfluous padding on layer 2 links shouldn't really affect protocol
performance aside from utilizing unnecessary bandwidth.
-Dylan
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
