Subject: RE: [tcpm] RFC2581bis

From: "Gil Jose-josegil1" <[email-masked]>
Date: Thu, 16 Feb 2006 15:26:56 -0000

A) I agree with Martin. It is too conservative and overkills the
throughput of the connection, especially in mobile cellular systems with
which I am more familiar and I can say that given the high RTT (and
RTO!) the impact on throughput is quite dramatic.

Do we need to be a bit more precise? For example, what about a timeout
during the loss recovery phase? At the time of the fast retransmit
ssthresh is set to half the value of cwnd. But if before the end of the
loss recovery phase there is a timeout then ssthresh is halved again as
I understand it from RFC 2581. My opinion is that this is also too
conservative.

B) My opinion is that such small change fits very appropriately into RFC
2581.

Jose

>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 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Mark Allman
Sent: 16 February 2006 14:52
To: Duke, Martin
Cc: Ethan Blanton; [email-masked]; [email-masked]
Subject: Re: [tcpm] RFC2581bis 

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

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

---

From: "Michael Welzl" <[email-masked]>
Date: Thu, 16 Feb 2006 16:46:02 +0100

Hi all,

I have no opinion about A) (i.e. I'd rather leave this to people who
have some operational experience with this matter), but agree about B)
(fits in the 2581 update).

Cheers,
Michael

----- Original Message ----- 
From: "Gil Jose-josegil1" <[email-masked]>
To: <[email-masked]>; "Duke, Martin" <[email-masked]>
Cc: "Ethan Blanton" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Thursday, February 16, 2006 4:26 PM
Subject: RE: [tcpm] RFC2581bis

Jose

Thanks!

allman