> On 7 Oct, 2015, at 21:05, David Lang <[email protected]> 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). - Jonathan Morton _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
