Subject: Re: [tcpm] RFC2581bis

From: Mark Allman <[email-masked]>
Date: Thu, 16 Feb 2006 09:51:37 -0500

Folks-

> I have concerns about setting ssthresh after multiple timeouts
> (Equation 5).  My initial feeling is that cutting ssthresh in half
> each time is too conservative.
>
> [...]
> 
> So as an alternative, perhaps we should leave ssthresh unchanged after
> the first retransmit.

Vern, Ethan and I have been chatting about this proposal.  We're a
little bit torn here because:

  * Our intent was to revise RFC 2581 for two reasons: (1) to roll in
    small changes to TCP that are already standards track (e.g., limited
    transmit and the larger initial window) and (2) to fix bugs
    identified in 2581.  It seems to us that the above is outside the
    scope of either of these tasks.

  * It seems to the three of us that setting ssthresh on the first RTO
    and then not adjusting it on subsequent RTOs for the same sequence
    number is safe and may well be a reasonable path.

So, how to reconcile these things?  Do we really want to require Martin
(or someone) to write a standards track RFC for something so small such
that it can someday be rolled into the main spec?  That seems like a
pretty high price.

So, we're asking the WG whether (a) the change seems reasonable and (b)
whether it is OK to include this small tweak into the current revision
of RFC2581.

(Note: (b) is being asked about this small change only.  We still think
that (1) and (2) should be the guiding principles for the revision.
Although, of course, the WG can decide otherwise, as well.)

Thanks!

allman

-- 
Mark Allman -- ICIR/ICSI -- http://www.icir.org/mallman/

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

---

From: Joe Touch <[email-masked]>
Date: Thu, 16 Feb 2006 11:21:50 -0800

I agree with Mark:

	- the modification needed is beyond the scope of 2581bis

The change should be documented as either proposed standard or
experimental (the latter justified since it's out in the wild anyway),
at which point 2581bis could cite it, but coupling these two documents
(one in-hand, one not even drafted yet) would stall 2581bis far too long.

There will always be mods to TCP that occur after any particular
document revision; let's not hold one up over the other.

Joe

Mark Allman wrote:
> ------------------------------------------------------------------------
>

---

From: "Armando L. Caro, Jr." <[email-masked]>
Date: Thu, 16 Feb 2006 16:01:22 -0500

I agree with Joe. Not only would this change stall the 2581bis, but it
would create a precedent that we might regret later. New ideas,
regardless of how small they may seem, should follow the normal course
of events. There will most likely be a 2581bis-bis later on down the road.

-- 
Armando
www.armandocaro.net

---

From: David Borman <[email-masked]>
Date: Thu, 16 Feb 2006 15:19:04 -0600

How about adding it as an appendix or a discussion item?  That would  
document the issue and the proposed solution, but defer making it  
part of the standard.

			-David Borman

---

From: Joe Touch <[email-masked]>
Date: Thu, 16 Feb 2006 13:26:43 -0800

David Borman wrote:
> document the issue and the proposed solution, but defer making it  part
> of the standard.
> 
>             -David Borman

It could/should be listed as an open issue, under "pending mods that are
not covered by this document".

(I'd avoid an appendix devoted to this issue; IMO, the issue should be
covered elsewhere in detail, not in this doc).

Joe