Subject: RE: [rohc] TCP compression profile

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Mon, 3 Mar 2003 13:07:29 +0100

> > > The main piece currently missing from the drafts is a description
> > > of how to encode each field in the TCP/IP header, so we've added a
> > > very simple proposal for this based on the current behavior draft.
> > 
> > How to encode the original fields are rather well "suggested" in the
> > behavior draft
> 
> This certainly seems to be the case based on our initial test 
> TCP flows. One interesting open issue, however, is the level of
> complexity needed in the final TCP encoding.  Our current
> implementation only uses a very basic set of packet formats,
> designed specifically to be human-readable.

Are these documented anywhere?

> If we choose the former approach then the notation defines
> which encoding methods are applied to which fields (including
> the "control" fields not present in the original TCP/IP header).
> To get  from this to "bits on the wire", we just need to
> define a library of 4 or 5 basic encoding methods for the
> notation to use.

I do not follow this. Can you maybe clarify better how this
would be done? In principle? How do you capture all functional
design decisions? Interaction with the context, feedback handling,
trade-offs between optimizing for the most common cases, the
average header size, etc?

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

---

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Tue, 11 Mar 2003 17:13:01 +0100

Richard,

> > One interesting open issue, however, is the level of

Can you send the TCP packet formats you used to the mailing list?

Thanks,
/L-E

---

From: "Price, Richard" <[email-masked]>
Date: Tue, 11 Mar 2003 16:50:19 -0000

> Can you send the TCP packet formats you used to the mailing list?

No problem.  Would you like them in notated or pictorial form (or
both, for comparison)?

If you'd like the packet formats in pictorial form, are the pictures
themselves sufficient or should all of the ancillary information
needed to get "bits on the wire" also be included (e.g. field
dependencies, interpretation intervals for LSB encoding, context
updating properties etc.)?

Regards,

Richard

---

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Tue, 11 Mar 2003 23:16:22 +0100

> updating properties etc.)?

I think the pictorial form would be ok also without the "rules" for how
to interpret the bits. Together with the notation form, it would be a
good example.

Thanks!
/L-E