Subject: [tsvwg] UDP options - FRAG+LITE

From: Derek Fawcus <[email-masked]>
Date: Sun, 4 Mar 2018 22:56:50 +0000

This was buried in the other thread, so pulling this out in to its own one:

Looking at it again, I may have been misinterpreting how LITE+FRAG
is to be used.  I was reading it as still performing the same 'swap some bytes'
logic as used for LITE alone.  However looking again at Figure 8, maybe
Joe means 'slide the LITE ahead of the 'LiteFrag'.  Please clarify.

DF

---

From: Joe Touch <[email-masked]>
Date: Sun, 4 Mar 2018 15:07:11 -0800

> Joe means 'slide the LITE ahead of the 'LiteFrag'.  Please clarify.

Fig 8 is ACS. I’ve lost context.

Can you ask the question again and clarify which fig you’re referring to?

Joe

---

From: Derek Fawcus <[email-masked]>
Date: Sun, 4 Mar 2018 23:22:00 +0000

> Can you ask the question again and clarify which fig you’re referring to?

Sorry Fig 18 - sect 5.8.1.

DF

---

From: Derek Fawcus <[email-masked]>
Date: Sun, 4 Mar 2018 23:29:31 +0000

> Sorry Fig 18 - sect 5.8.1.

Compare it to Fig 12 for LITE alone.  In fig 12 the arrow points to 'Ldat',
data swapped from the front of the 'Lite data' section, whereas in 18 it points
to the FRAG header. Suggesting sliding blocks, vs if it point to say 'LFdat'
i.e. data swapped from the front of the 'Lite Frag' section.

So I'm asking if the swap mechanism used for LITE alone is supposed to be used
for LITE+FRAG, or if you intend some other mechanism?

I'm reading Fig 18 as suggesting a different mechanism, i.e. reorder the chunks
from the order 'Lite Frag', 'LITE', 'FRAG' to be in the order 'LITE', 'Lite Frag',
'FRAG', which would entail rewriting all of the bytes between the UDP header and
the FRAG header.

DF

---

From: Joe Touch <[email-masked]>
Date: Sun, 4 Mar 2018 16:26:55 -0800

In LITE, on transmission:

	info ordering starts as shown in Fig 10 (or 11 - same thing):
		UDPpayload / LITEdata[0..n] / LITEopthdr / otherheaders

	the first 4 bytes of LITEdata are swapped with the LITEopthdr as shown in Fig 12:
		UDPpayload / LITEopthdr / LITEdata[4…n] / LITEdata[0..3] / otherheaders

On reception, the sequence is reversed once the LITEopthdr is seen.

——

Figs 17 and 18 are intended to just be an instance of Figs 10/11 and 12 (respectively) with the following specifics:

	a) UDPpayload is null (i.e., 0 bytes)
	b) otherheaders starts with the FRAGopthdr

(Fig 18 doesn’t quite show the LITEdata[0…3] where it should be - I’ll fix that)

I.e., there’s nothing different here. Nothing “slides”; it's (intended to be) the same swap operation.

Joe

> On Mar 4, 2018, at 3:29 PM, Derek Fawcus <[email-masked]> wrote:
>

---

From: Derek Fawcus <[email-masked]>
Date: Mon, 5 Mar 2018 13:10:48 +0000

> I.e., there’s nothing different here. Nothing “slides”; it's (intended to be) the same swap operation.

Thanks, I just wanted to make sure before I tried coding something up.

DF