Re: A puzzled maintainer with questions regarding

["M.Baris Demiray" <barisdemiray () gmail com>]

On Thu, Feb 3, 2011 at 9:54 PM, Guy Harris <guy () alum mit edu> wrote:
> On Feb 3, 2011, at 8:47 AM, M.Baris Demiray wrote:
>
> > Hello again,
> >
> > I have solved almost all the problems that I mentioned below and now I
> > am sure that I should ask for a new DLT value for STANAG 5066 [1] MAC
> > (Medium Access Control Sublayer) PDUs. Currently I am able to dissect
> > these PDUs using DLT number 147 (USER0) using Wireshark 1.4.3 and I'd
> > like to have this dissector and corresponding DLT value in the main
> > stream.
> >
> > I might add that STANAG 5066 SIS layer is already defined in Wireshark
> > [2] yet it can only dissect the packets transferred between STANAG
> > 5066 and its clients.
>
> OK, that answers the questions I asked in my previous message.
>
> > Now, what I propose is to have the same
> > functionality for the interface between STANAG 5066 and HF modem as
> > well. What else should I provide regarding this protocol to ask for a
> > DLT value?
>
> So that protocol is presumably the one mentioned in the isode.com white paper:

Correct,

>        At the modem level, STANAG 5066 uses packets (DPDUs) of a size appropriate to the modem speed. At 1200 
> bits/second 128 bytes will be used, which is much less than the typical Unit Data. Benefits of using smaller DPDUs 
> include:

In fact this is not what STANAG 5066 Annex H "Implementation Guide and
Notes" section suggests. According to this section and the tests held
by DRA (Defence Research Agency),

1) The throughput is not strongly sensitive to frame size
2) 200 bytes is a good 'compromise' selection for frame size

Besides, STANAG 5066 has the ability of doing DRC (Data Rate Change)
in accordance with SNR values so what is suggested by that white
paper, I think, is not applicable.

>                • Acknowledgement is done for each DPDU, so if data loss occurs when transmitting a DPDU, only that 
> DPDU (and not the whole Unit Data) need to be retransmitted.
>                • When higher precedence Unit Data arrives is sent for transmission by a STANAG 5066 server, sending 
> can begin after transmission of the current DPDU (i.e., there is no need to wait for the full Unit Data transmission).
> Acknowledgements, often referred to as ARQ (Acknowledgement ReQuest), are used for Reliable Unit Data and are made 
> for each DPDU. In order to minimize the number of turnarounds, sending of acknowledgements is delayed. A typical 
> sequence with two radios might be:
>
>                • Radio 1 transmits to Radio 2 for 127 seconds; it sends a number of DPDUs.
>                • Radio 2 transmits to Radio 1 for 127 seconds; it sends acknowledgments for the DPDUs received from 
> Radio 1; then it sends some DPDUs.
>                • Radio 1 transmits to Radio 2 for 127 seconds; it sends acknowledgements for the DPDUs received from 
> Radio 2; then it works out which DPDUs failed to transmit last time and resends them; then it sends more DPDUs.
>
> with the packets for the MAC layer being the DPDUs.  Is that correct?

Precisely. Yet may be a little clarification is needed. You might have
noticed that in my first e-mail I mentioned about DTS (Data Transfer
Sublayer) and that one of our dissector methods has the name
dissect_s5066dts() but now we are talking about MAC layer and all this
may look like a confusion but it is not. As explained in Isode white
paper there are three versions of STANAG 5066. MAC (Medium Access
Control) layer was introduced in Edition 2 (which was later renamed as
Edition 3) and designated to manage HF modem interface that DTS was
designated to do the same before.

Thanks,

> -
> This is the tcpdump-workers list.
> Visit https://cod.sandelman.ca/ to unsubscribe.

-- 
M. Baris Demiray
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.