Hi Pasi, > Carsten Bormann wrote: > > > > OK, let me phrase my question in another way: why does the spec > > > contain a feature that does not really work? (Even as optional > > > feature?) > > > > Well, it actually does work. > > > > RFC 4224, section 5.2.1 tells us that when a channel is reordering > > and you don't notice, packets will be lost. Now IPsec is a strange > > animal: It is reordering, but the order can be reconstructed from > > the sequence number. So a reassembler could (here really: SHOULD) > > use that to avoid stitching together packets in the wrong order and > > then discarding them. > > Well, the current drafts don't specify any such behavior, so the > feature as it's currently written does not work. (Also, using the > ESP/AH sequence number this way would be very unusual -- there > might be some complications...)
If we include text that states this behavior, does this address your concern? FWIW, I could also think of deployment scenarios where packet reordering is minimal (e.g., ROHCOIPsec is instantiated over a single [bandwidth constrained] link). Such scenarios may not even require the use of the ESP/AH sequence number to reconstruct ROHC segments. Best Regards, Emre > Best regards, > Psai > > _______________________________________________ > Rohc mailing list > r...@ietf.org > https://www.ietf.org/mailman/listinfo/rohc _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
