Hello,

Except perhaps in cases of sequenc number wrap-around, is it ever
legitimate for the ACK value in a TCP segment to be greater than the
left edge of the leftmost block in the accompanying SACK options? I'm
seeing packets like this coming back from an FTP server X.X.X.X (the
remote client Y.Y.Y.Y is doing an active-mode STOR, but I don't show
those packets here):

11:09:11.162335 IP (tos 0x0, ttl 64, id 2075, offset 0, flags [DF],
length: 72) X.X.X.X.20 > Y.Y.Y.Y.2565: . [tcp sum ok] 1:1(0) ack 99543
win 10912 <nop,nop,timestamp 924970291 6793494,nop,nop,sack sack 2
{96739:98129}{100945:119171} >

11:09:11.175782 IP (tos 0x0, ttl 64, id 2081, offset 0, flags [DF],
length: 64) X.X.X.X.20 > Y.Y.Y.Y.2565: . [tcp sum ok] 1:1(0) ack 119171
win 11596 <nop,nop,timestamp 924970294 6793494,nop,nop,sack sack 1
{100945:102335} >

My understanding was that the ACK value always represents just what it
does without SACK -- the right edge of contiguous received data, so in
that interpretation the ACK values above don't seem to make sense.

Thanks for any insights!

Med