Subject: RE: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?]
From: "Anantha Ramaiah (ananth)" <[email-masked]>
To: "Joe Touch" <[email-masked]>
Cc: [email-masked]
Date: Wed, 21 Nov 2007 12:35:08 -0800
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>

> -----Original Message-----
> From: Joe Touch [mailto:[email-masked]] 
> Sent: Wednesday, November 21, 2007 10:59 AM
> To: Anantha Ramaiah (ananth)
> Cc: [email-masked]
> Subject: Re: Summary of responses so far and proposal moving 
> forward [Was Re: [tcpm] Is this a problem?]
> 
> I think it would be very useful to highlight the problem and 
> provide information on how to solve it at the application 
> layer in an informational RFC. I'd suggest it'd be useful to 
> include very specific examples, e.g., with socket options, to 
> show a potential mechanism. I also think the doc should 
> include a discussion of making slow progress as related to 
> this issue, and potentially a similar DOS opportunity.

Actually the mention of socket option is not explicit as it stands now
in the draft and there is definetly some scope for re-wording, I think.

> 
> I don't think the doc should change 1122's text; IMO, TCP 
> isn't the one who ought to make this decision, thus TCP ought 
> to hang out as long as the application lets it.

Pl see my response to Ted where I explicitly ask a question and provide
why I think there is "some" element of standarization here, your
responses are welcome.

> 
> I don't think the doc should mention whether the timer should 
> be embedded in TCP as an implementation decision. IMO, that 
> crosses into a TCP mod, and since it isn't absolutely 
> necessary, I don't see a reason to do so there. I do think it 
> would be more useful to give the example of putting this in 
> the kernel as a shared mechanism, with discussion to motivate it.

Hmm.. An informational RFC CAN recommend stuff, confused here??

> 
> Finally, if this is an informational RFC and the solution is 
> soley at the app layer, it ought to be taken to TSVWG, rather 
> than in TCPM. I don't consider this a downgrading, but rather 
> to gain a wider audience for a very real issue.

Well, agree with the rationale but not the reasoning. My reasoning may
be :- "since this real issue applies equally well for SCTP as well AND
also to gain a wider audience, may be it is a good idea to take this to
tsvwg".

-Anantha

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