Re: Reminder: 2.5g3g wg last call ends Friday

[Gorry Fairhurst <[e-mail]>]

The recent draft-ietf-pilc-2.5g3g-03 seems to still need a lot
of work, before the recommendations become precise enough to
comment on in detail. I have a number of specific comments which
you may like to compare with others which have been sent to the list. 
I'm sorry if there is overlap in some cases with these other comments,
and apologize for the lateness - I've been on vacation.

-------

I think the discussion of end host configurations, largely says "use an
up to date" TCP stack, and describes the current features as of today
which would be expected. 

> 1. Introduction
-Perhaps it would be beneficial to preface it by a more clear
description 
of who the information is expected to be read by? 
- TCP implementors? Providers offering content servers? 2.5/3G operators?
ISPs? and/or people implementing TCP/IP stacks to be used over such subnets?

-------

Comments on some points in 3/4:

> 3.1.1 Large window size
>   To achieve the maximum performance in TCP, the advertised receive
>   window size needs to be equal to or greater than the BDP (Bandwidth
>   Delay Product) of the end-to-end path.

I don't like the term "maximum performance" - this is too vague.
Performance achieved by applications is dependent on what they are trying
to do. Telnet may not benefit from large windows, streaming audio
may be somewhat different from bulk file transfer via ftp, or nfs
over TCP.  Sessions which send only a small number of bytes
never benefit form TCP-LW.  This statement therefore seems too vague, 
and you need to be more precise about the conditions which are likely
to benefit from using this.

> the link BDP tends to large

This is very vague, you probably do need to clarify.

> The receiver must advertise the appropriate receive
>  window size based on the end-to-end BDP. 

This probably needs to be rephrased.  "must",
may perhaps be better replaced by "should" and
give reasons why it may choose to.  Note that the
receiver COULD be remote in the Internet, and not under the
control of any 2.5/3G network.

> If the estimated path BDP is larger than 64 KB,
>  the window scale option may be deployed. 

The option needs to negotiated by both sender and receiver.
This isn't clear, but has significant implications on 
deployment and usage of TCP-LW.

> Although the increased initial
>   congestion window is experimental status, the impact of use of it to
>   the majority of the Internet can be mitigated if the split
>   architecture[36] is deployed that terminates TCP connection between
>   the mobile node and the gateway and could set the CWND > 2 segments
 >  only to the TCP connection to the mobile node. Be careful on the
>  implications caused by the use of the transport gateway, which
>   includes end-to-end argument, mobility and security[36].

The English here obscures the meaning - I don't think the dangers
of the approach are clearly identified. 

Does this ID really advocate  "careful" split-tcp as an IETF recommended 
approach??? - If so, under what conditions? - and with what trade-offs?

> TCP over 2.5G/3G should allow freedom for designers to
>   choose MTU from a small value (such as 576B) to a large value (up to
>  1500B). 

"such as 576 B" --- is this a lower bound? (I think so) 
"up to 1500B" --- why this maximum? (this is a good minimum,
based on Ethernet MTU,  for many current Internet paths, but larger
MTUs are sometimes used).

N.B. It would be wise to say that these values apply to IPv4.

This statement actually goes against the general recommendation to
use large MTUs - expressed elsewhere in PILC, maybe it would be
worth saying "in general a large MTU should be supported..."

----

> "We have been interested in T/TCP (Transaction/TCP)"

A rather bizarre statement in a WG Internet Draft !!!

>  we did not recommend T/TCP in this document. 

Did not - or do not ??? - I trust PILC still does not recommend??

>   Eifel algorithm [19] is an enhancement to TCP's error recovery
> ...spurious timeouts and spurious fast
>   retransmits....

This is not tied in with the conditions under which the losses happen,
-what causes these TCP effects?
The current text does not seem to help a link designer know whether 
this is actually going to be needed in her/his network.

There also needs to be clearer guidance on whether this requires
the TCP sender or receiver or both to be changed.

> We should watch more evaluation and deployment/standardization
>   status of Eifel and D-SACK in the wireless environment. 

Not sure I understand what "watch" means. Can you be specific
about what benefits you expect?

Is the transport area likely to standardize Eifel?

> Security considerations
> In 2.5G/3G wireless network, data transmission in ciphertext is
>  limited only over the air, but cleartext between RAN and core
>  network. 

"RAN" - define.
This isn't clear, what does it mean and how does this relate to Internet
security?

----

I didn't find the current version of the ID easy to read. I doubt if it is
complete in discussing all issues relevant to TCP/IP over 2.5/3G.

Gorry