In-band lib, the original intention of 'tag'

GNU Radio
1

What was the original intention of the ‘tag’ field in the in-band USB
packet header?

As I play more and more the in-band stuff and MAC designs, I’m beginning
to realize we are missing one major thing: notification of packet
transmission.

I think this is a missing piece. It would be extremely useful to the
host if it could determine that its packet was not transmitted. For
example, the packet was sent with an expired timestamp and was thrown
away. The host has no way of knowing the packet was not transmitted.

I’m not sure if this was the original intention of the tag, but it would
be extremely useful. My guess is that the tag was meant to be sort of
like the invocation handle. I think this would be sufficient enough for
determining success.

Our queue is big enough for 4 packets (off the top of my head),
therefore the tag would only need a history of size 4. The tag is 4
bits, the bottom 3 bits could be used as a relative packet number, and
the top bit notifies success or failure.

This is an extremely important feature for our MAC enhancements, where
we implement time-critical functionality like carrier sense on the
board. Aside from timestamps expiring, if our carrier sense decides to
throw away a packet, it is important for the host to know. Therefore,
we need some feedback mechanism. I’m going to implement some feedback
mechanism period, I’m just trying to coordinate with the larger
framework so it’s useful for more than just myself :slight_smile:

  • George
2

On Thu, May 01, 2008 at 01:04:26PM -0400, George N. wrote:

What was the original intention of the ‘tag’ field in the in-band USB
packet header?

I think I was thinking of something like an invocation handle.

As I play more and more the in-band stuff and MAC designs, I’m beginning to
realize we are missing one major thing: notification of packet
transmission.

Packet transmission, or failure to transmit?

I think this is a missing piece. It would be extremely useful to the host
if it could determine that its packet was not transmitted. For example,
the packet was sent with an expired timestamp and was thrown away. The
host has no way of knowing the packet was not transmitted.

If you’re going to ack all of them, you’re going to burn up ~1/2 the
USB bandwidth.

I’m not sure if this was the original intention of the tag, but it would be
extremely useful. My guess is that the tag was meant to be sort of like
the invocation handle. I think this would be sufficient enough for
determining success.

Our queue is big enough for 4 packets (off the top of my head), therefore
the tag would only need a history of size 4. The tag is 4 bits, the bottom
3 bits could be used as a relative packet number, and the top bit notifies
success or failure.

This is an extremely important feature for our MAC enhancements, where we
implement time-critical functionality like carrier sense on the board.
Aside from timestamps expiring, if our carrier sense decides to throw away
a packet, it is important for the host to know. Therefore, we need some
feedback mechanism. I’m going to implement some feedback mechanism period,
I’m just trying to coordinate with the larger framework so it’s useful for
more than just myself :slight_smile:

How about just reporting problems? Would a single bit do it, or do
you need to know which packet/frame had the problem? IIRC there are
three unused bits in the header. Perhaps you want to expand tag to 5
bits then use one of the others for an error indicator.

I think you’re going to want to piggy back these on any Rx data if you
can, else send them by themselves.

Let us know what you come up with.

Eric

3

Eric B. wrote

If you’re going to ack all of them, you’re going to burn up ~1/2 the
USB bandwidth.

Definitely being piggy backed on RX frames.

How about just reporting problems? Would a single bit do it, or do
you need to know which packet/frame had the problem? IIRC there are
three unused bits in the header. Perhaps you want to expand tag to 5
bits then use one of the others for an error indicator.

If you just report failure it makes the FSM of MAC’s more difficult, you
need to wait for some amount of time before you decide that a failure
occurred. If I had to pick 1, I’d say report on transmit, but I think
we can get away with reporting both.

It would be extremely useful for all of this to be masked from the app
in usrp_server.cc, when it gets a start-of-burst, it marks the tag with
a 3 bit value using a local wrap-around value. It then holds all
transmit responses until it sees an RX packet carrying this tag in the
bottom 3 bits, and then it checks the top bit for 0 or 1 to determine
success. It then can respond with the transmission status. All that
happens now is that as soon as its written to the bus, the “tx success”
gets passed up. In fact, i think its impossible to get a “tx failure”
since you block when the USB bus is full.

I should be able to get away with the 4 tag bits, unless the queue size
is bigger than 7 packets, which i don’t think it is.

Let me know if you have any suggestions, I need to implement this by
next week, likely over the weekend.

  • George
4

Eric B. wrote:

You want to make sure that in adding your feature, you don’t break
other usage models. E.g., an app that is Tx only at 8 MS/s.

True, I didn’t think about this. I will include some functionality that
if the RX is disabled, then the packet transmission feedback is
disabled.

I don’t think you should overload the tag field with the error bit.
Pick another unused bit for the error indicator.

No problem, I’ll steal the closest mbz bit to the tag.

OK. Please do it on a branch :slight_smile:

Will do!

  • George
5

On Thu, May 01, 2008 at 01:40:22PM -0400, George N. wrote:

you need to know which packet/frame had the problem? IIRC there are
three unused bits in the header. Perhaps you want to expand tag to 5
bits then use one of the others for an error indicator.

If you just report failure it makes the FSM of MAC’s more difficult, you
need to wait for some amount of time before you decide that a failure
occurred. If I had to pick 1, I’d say report on transmit, but I think we
can get away with reporting both.

OK.

It would be extremely useful for all of this to be masked from the app in
usrp_server.cc, when it gets a start-of-burst, it marks the tag with a 3
bit value using a local wrap-around value. It then holds all transmit
responses until it sees an RX packet carrying this tag in the bottom 3
bits, and then it checks the top bit for 0 or 1 to determine success.

You want to make sure that in adding your feature, you don’t break
other usage models. E.g., an app that is Tx only at 8 MS/s.

I don’t think you should overload the tag field with the error bit.
Pick another unused bit for the error indicator.

It then can respond with the transmission status. All that happens now is
that as soon as its written to the bus, the “tx success” gets passed up.
In fact, i think its impossible to get a “tx failure” since you block when
the USB bus is full.

We’ll probably have to sort that out sooner or later. It would be
nice to be able to use something like “select” on the usrp interface.

I should be able to get away with the 4 tag bits, unless the queue size is
bigger than 7 packets, which i don’t think it is.

Let me know if you have any suggestions, I need to implement this by next
week, likely over the weekend.

OK. Please do it on a branch :slight_smile:

Eric