On Wed, 7 Oct 2015, Jonathan Morton wrote:
On 7 Oct, 2015, at 21:05, David Lang <da...@lang.hm> wrote:
It’s not “in the wild”, but this sort of thing is a headache for ELR. It
essentially means that it won’t be able to use AccECN for its feedback
(since AccECN doesn’t allow reconstructing a complex 32-packet history of
ECN codepoints from a single ACK), but must introduce some other mechanism
to feed back the required data to the sender.
but if you are getting all 32 acks at the same time, with no other packets
flowing, are you going to be able to do anything sane? do you mark every one
of the acks with ECN (sending a super-strong backoff message), or only mark
one of the acks (sending a weak backoff message)
Also, how can you tell how many acks you 'should' get? what happens if the
1500 byte packets get combined into 9000 byte jumbo packets for the final
hop? how many acks 'should' you get?
Let me turn that around:
What should a node which aggregates 1500-byte packets into jumbo frames set
the ECN field to on the resulting jumbo packet, if the ECN fields of the
original packets had different values? I’m having some trouble imagining a
scenario where such destructive aggregation is permitted, except for TCP
proxies which should act as endpoints anyway. GSO, in particular, requires
the headers to be identical in that respect, ensuring that the original
packets can be reconstructed (assuming they are MSS sized).
TCP data is supposed to be logically a continuous stream, it should not matter
to the endpoints how it is packetized. So a conversion to/from jumbo frames
should be acceptable.
David Lang
_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
