Subject: RE: [rohc] TCP profile packet formats...

From: "Kristofer Sandlund (LU/EAB)" <[email-masked]>
Date: Wed, 31 Aug 2005 09:59:40 +0200

Hi Mark,

comments inline.

> 
> Hi all,
> 
> Hopefully it is only slightly unusual to have last-call 
> comments from an
> author of the draft.  However (confession time!), I haven't 
> stepped back
> and looked at the packet formats in detail for some time.  So 
> having gone
> through then, I thought that I'd try and pick up on a couple of
> inconsistencies before anyone else does...

Well, with the last-call end date passed, we have a total of zero
reviews, so I guess we soon will have to settle for the authors 
reviewing this spec.

> 
> These comments, therefore, relate solely to the construction 
> of the packet
> formats.
> 
> 
> * co_format_co_common
> 
> We had a cunning idea, based on TCP flag usage, that only 2 bits were
> required to convey the RST, SYN and FIN flags, since certain 
> combinations
> were unlikely to the point of impossibility.  Does it 
> actually make sense
> to retain this encoding in the 'common' packet format?  Or is 
> it better to
> explicitly carry all three flags (which, I note, means 
> finding another bit
> from somewhere)?

Aren't you contradicting yourself here? First you say that it is
almost impossible that we need all three, and then you say that
we should code them as three bits.... Unless we have have some
indication of all three being needed, I think we should stay with
what we have. I'm very stretched out on bits in that packet 
format so I wouldn't know where to find that last bit either.
(note that we cannot mess with this discriminator since it is
from the "IR-DYN" space)

> 
> [and I'm really not sure myself, hence the question!]
> 
> 
> * co_format_rnd_7 / co_format_rnd_9
> 
> Both of these are distinguished by the combination of a 
> sequence number
> change (scaled and non-) and a window change.  Window changes are
> advertised from the receiver.  Window updates can clearly 
> occur without an
> ack number change.  However, I can't think of any obvious 
> cases where a
> window change will occur *with* a SN change and *not* an ack change.
> Format 8 neatly covers the (unscaled) ACK + window change.  I suggest
> changing the scaled SN packet to cover the scaled ACK case, 
> and losing the
> unnecessary unscaled SN.
> 
> [this situation is also reflected in the non-random IP-ID formats]

Ouch. I guess what you're saying makes sense, but before we decide, I hope we can get input from some of the tcpm people.
But _if_ we decide to drop format_7, then I have to play "discriminator bingo" once again, and try to 
optimize the discriminator tree. That is likely to affect a 
number of formats (and hopefully should find some use for the 
extra bits they get, but many formats are already at 16 bits on 
SEQ/ACK and then it I don't really want to increase them). I'll 
try to make a test-run later today and see if it will make sense 
to do this. And if it doesn't make sense to stretch out every last 
bit possible, I don't think we need to cry about that either.

Anyway, good catch on this. I think we'll wait for some more 
feedback before we take a decision.

/Kristofer

> 
> 
> My feeling is that, overall, we have a pragmatic set of 
> formats that cover
> TCP usage pretty well [many thanks to all my co-authors and especially
> Kris for this!].  The above points are all that struck me on a more
> thorough re-read and, of those, the latter one is the only substantive
> comment.  (Obviously I await with interest the feelings of those more
> experienced in the ways of TCP!)
> 
> 
> Cheers,
> 
> Mark.
> 
> 
> 
> 
> _______________________________________________
> Rohc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rohc
> 

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Mark West <[email-masked]>
Date: Wed, 31 Aug 2005 11:55:10 +0100 (BST)

Hi Kris,

Thanks for the feedback.

> reviews, so I guess we soon will have to settle for the authors

My understanding is that the last-call 'deadline' is a bit flexible... to
give the reviewers time to digest the specs (they are not, in all honesty,
the most digestable documents ever created!)

I just wanted to beat the rush :-)

> (note that we cannot mess with this discriminator since it is

Yes, I'm being slightly self-contradictory.  And..?! ;-)

On the one hand, I feel on reasonably safe ground: RFC 1144 uses
'implausible' combinations of flags to signal special cases, with the
caveat that a packet matching this case must be sent uncompressed.  This
is a reasonable argument here, I think.

On the other hand, it would be nice to be able to handle 'unusual' cases
without resorting to sending uncompressed packets.

I take your point about being stretched for bits and, unless a TCP expert
screams at me, I'm happy to leave it as-is.

> bit possible, I don't think we need to cry about that either.

If we could find another useful format to substiture for format_7, that
would also be a possibility.  I've been thinking about possible
alternatives, but have no great ideas yet.

I don't think that it would be disastrous to increase SEQ/ACK bits beyond
16, although I also can't see a strong need for it.  And I also agree that
if we end up with a 'spare' bit in one or two cases, that is also not
necessarily the end of the world!

Let's wait for the final review comments, though, and then decide what to
do.  But I guess we'll have to do something...

Cheers,

Mark.