Subject: RE: [rohc] Issue list for ROHC TCP

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Tue, 15 Feb 2005 13:21:58 +0100

Any way is fine with me, what I care about is that the list is
part of the detailed process. I can keep track of the issues,
and then I will do it on the list only. If someone else want to
do it, they can use the tracker, but *everything* must still be
sent also to the list, including all discussions on how to resolve
issues, of course.

So, discuss the issues listed so far, and add new issues by
sending a mail to the list, I'll keep track of them.

/L-E

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Ghyslain Pelletier (LU/EAB)
> Sent: den 15 februari 2005 13:02
> To: [email-masked]'
> Subject: RE: [rohc] Issue list for ROHC TCP
> 
> 
> > Follow up on these and add new issues, I'll try to keep track of
> > which have been closed/added/updated and re-post this regularily.
> 
> Shouldn't we try to use the issue tracker instead, and state 
> on the list when/what to add to the tracker instead? I think 
> the problem is the the tool itself, but rather our lack of 
> discipline in using it?
> 
> In any case, of course it is good to keep track of issues one 
> way or another - good initiative to bring that back on the table!
> 
> /Ghyslain
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: den 15 februari 2005 11:53
> > To: [email-masked]'
> > Subject: [rohc] Issue list for ROHC TCP
> > 
> > 
> > Folks,
> > 
> > I've tried to identify the currently open issues for 
> > ROHC-TCP. Probably
> > there are more issues than this, but it is a start and others should
> > fill in the missing pieces. I know there is an issue tracker 
> > available,
> > but to me it is clear that it does not work for several 
> reasons; e.g.
> > the fact that it is not used (updated), and the mail list is not
> > informed of changes, which is a fundamental requirement if 
> we want to
> > use such external tools (the mail list is our work archive and the
> > public place where people should be able to follow what is 
> going on).
> > 
> > So, the open issues I know of right now are:
> > 
> > TCP-1: Does ack and seq scaling have a zero-division issue since
> >        they appear in the default_methods section?
> > 
> > TCP-2: Ack scaling could be applied to a larger number of packet
> >        formats. Maybe let _10 and/or _8 use one bit to indicate
> >        of ack is scaled or not and in that case use 8 bits less?
> > 
> > TCP-3: Since list compression is not defined by FN anymore, text
> >        for that is needed in the TCP-draft.
> > 
> > TCP-4: We need text on wrap-around of SN/ACK-SN when using scaling.
> > 
> > TCP-5: At least a few people must independently review the content
> >        of the packet formats so that we have some confidence in
> >        them.
> > 
> > Follow up on these and add new issues, I'll try to keep track of
> > which have been closed/added/updated and re-post this regularily.
> > 
> > /L-E
> > 
> > 
> > --------------------------------------
> > Lars-Erik Jonsson
> > IETF ROHC WG Chair
> > E-mail: [email-masked]
> > Phone: +46 8 404 29 61
> > 
> > _______________________________________________
> > Rohc mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/rohc
> > 
> 
> _______________________________________________
> 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: "West, Mark" <[email-masked]>
Date: Wed, 16 Feb 2005 23:48:12 +0000 (GMT)

Hi all,

Some off-the-top-of-my-head answers to the current open issues (I need to
be more awake to think coherently about whether there are other issues...)

> > >        they appear in the default_methods section?

My understanding is that we should be specifying what happens at the
*decompressor*, rather than the *compressor*.  If we can stick to this,
then I believe that div-by-0 goes away?

> > >        of ack is scaled or not and in that case use 8 bits less?

My [admittedly] brief investigations of ack-scaling suggest that it only
makes sense for a limited number of bits (scaling factor).  Long runs of
acks that scale by more than 3 bits are, at least in my samples, quite
limited.  Whether this makes it worth scaling is unclear.

> > > TCP-4: We need text on wrap-around of SN/ACK-SN when using scaling.

Agreed.  But I don't think that there are any particularly nasty cases
here.

> > >        of the packet formats so that we have some confidence in

I don't know if I count as an independent reviewer of the packet formats,
but I'll certainly undertake to look at them.

Cheers,

Mark.