jdev - 2022-05-03

Someone didn’t read until the end?

lovetox, the idea is that you can have multiple identities that assign <stanza-id/>s. like e-mail messages get assigned an ID by every mail server hop

so if you have a 1:1 message from foo@source.org to bar@target.org, the message could have <stanza-id by='foo@source.org' id='an-id'> and <stanza-id by='bar@target.org' id='another-id'>

lovetox, note that I don't believe that there is anything in the spec that limits what can be an id-assigning entity. But I see how the current wording might be confusing

Martin, padding length is always a tradeoff between maximum original-length disguise and traffic reduction

Martin, an Ethernet frame is about 1500 bytes, so it makes sense to optimise to stay under this limit (taking into account the Ethernet and IP and TCP headers) but not much further.

200 bytes might make you cross this border, but you already have to have a hefty stanza.

I don’t know about wifi or LTE though.

These might have smaller frame sizes.

I sure can't hurt to keep the MTU in mind, but I wonder how relevant it is for a stream-based XMPP connection. Ideally multiple XML elements share the same layer 2 packet

Link Mauve: LTE and WiFi all have the same MTU, which goes back to the horse asses of the Roman Empire.

:D

the only notable exception is PPPoE as implemented by many DSL providers, which takes away 28 bytes and makes networks cursed that filter ICMP

clamp-mss-to-mtu or something

And every kind of tunnel reduces MTU also

Maranda: there are also tunnels that will just fragment the hell out of your packets

🤩

openvpn?

jonas’: how do you know? ;)

pain and sorrow and why the fuck don't they just inject ICMP fragmentation needed like a sane person?

vlan also uses up some MTU. And satellite internet uses a lot of VLAN internally, in addition to using IP-over-MPEG which probably results in strange MTU things

pulkomandy: in most deployments, VLANs grow on the outside and not on the inside of the Ethernet frame

The vlan tag is added between the src/dest addresses and the remaining part of the frame. So it's not really on the outside either. And also, we actually used vxlan, which is basically ethernet-over-udp, to do things in the worst possible way

yay for worst possible ways!

well, vxlan is not the /worst/ possible way

given that VLAN is restricted to 4094 networks, which is easily not enough in some settings.

what's with the other two?

Before using vxlan, we had 3 nested levels of vlans to overcome the 4094 networks limitation

Ge0rG, I think 0 and 4096 are reserved.

oh, and default vlan == 1 and not 0

> The reserved value 0x000 indicates that the frame does not carry a VLAN ID; in this case, the 802.1Q tag specifies only a priority (in PCP and DEI fields) and is referred to as a priority tag. On bridges, VID 0x001 (the default VLAN ID) is often reserved for a network management VLAN; this is vendor-specific. The VID value 0xFFF is reserved for implementation use; it must not be configured or transmitted. 0xFFF can be used to indicate a wildcard match in management operations or filtering database entries.

TIL

Now we need a VLAN XEP to make this on-topic

Link Mauve: > 200 bytes might make you cross this border, but you already have to have a hefty stanza. I just wondered why 200 bytes and not 100.

Ah, 200 characters, not bytes…